工作在無狀態的WCF休息Web服務上，並具有3個獨立任務的操作。每一個都可以獨立運行。每個任務都包含對外部API的Web服務調用，後續的本地數據庫讀取操作的時間少於0.25秒。WCF多線程與可伸縮性考慮
首先想到的是，我應該產生3個單獨的線程，然後加入並返回結果。使用線程池在這裏可能不是一個好主意，因爲它限制在250個最大值之內。
性能值得關注，但不以犧牲可擴展性爲代價。
我應該關心啓動&爲每個Web服務調用加入3個單獨的線程的開銷嗎？
將對外部服務的調用封裝到異步任務方法中，然後從您的WCF方法調用。它將使用線程池，並在線程拉伸耗盡時將您的Web服務調用很好地排隊。
您可以使用異步IO來執行web服務調用。異步IO在運行時不會佔用任何線程。你可以爲數據庫調用做同樣的事情。這可以緩解您可能遇到的任何線程問題。
或者，您可以依賴線程池。你可以增加限制。你可以計算你需要多少個線程：如果每秒有100個請求到達，每個請求需要2秒才能完成，你需要200個線程。假設您配置了適當的限制，這可以通過內置線程池輕鬆實現。
如果外部服務中斷並需要30秒超時，此數字現在可以拍攝多達3000個線程，我認爲這些線程是不安全的。所以你要麼需要一個很低的超時時間，斷路器或異步IO。
所以爲了決定你需要預測負載和延遲。
我會鏈接到一些討論爲什麼以及何時異步IO使用：
https://stackoverflow.com/a/25087273/122718爲什麼EF 6教程中使用臺異步調用？ https://stackoverflow.com/a/12796711/122718我們是否應該默認切換到使用異步I/O？
但是，這將違背可擴展性要求。線程池最多限制爲250個線程。 – AlexVPerl
線程池大小通常等於邏輯線程數乘以25.爲了擴展您的服務，您需要不斷增加服務可用的邏輯線程數。 –
我不認爲ThreadPool適合我的問題，由於線程數限制。我甚至不會考慮使用ThreadPool。直接使用線程，不會強加任何軟限制，只是您的硬件可以支持。 – AlexVPerl