Web應用程序中的多線程（WCF/WebAPI）

我有一個「引擎」，我想通過一個HTTP層（使用WebAPI/WCF託管）公開。Web應用程序中的多線程（WCF/WebAPI）

該引擎對大量數據執行一些簡單的只讀操作，並且可以從並行性中獲益。從（...）到Parallel.For（...）的簡單切換確實是奇蹟。

現在我認爲我們不應該在Web服務器上做這些多線程，所以我試圖找出主辦這種方式的最佳方式。

理想情況下，我希望這是作爲一個標準的Web應用程序與WebAPI或WCF託管在IIS中。如果這不是一個好的解決方案，那麼會是一個好的選擇？

在標準Windows服務中自行託管WebAPI或WCF會更好嗎？我不確定這裏的問題是IIS還是ASP.NET特定的。

或者這可不是問題，我只是擔心得太多？

任何輸入將不勝感激。

感謝

來源

2013-08-24 Pedro

我不是完全清楚您的問題是什麼，但我會盡力給你一定的基礎上，你可以決定：

可以在IIS/ASP.NET使用多線程安全。當然，有很多並行請求並不需要，因爲並行性發生在更高層次上（事實上，儘管吞吐量稍微有點受影響，但只是略微有點）。儘管可以使用較低級別的並行性（Parallel.For）來減少延遲，但併發請求很少。

因此，ASP.NET中的多線程更多地是減少延遲而不是增加吞吐量。

我不明白自託管如何改變這一切。

您似乎有點瀰漫性擔憂這是一種可行的方法。試着制定具體的問題，我會解決它們。

來源

2013-08-24 09:55:45 usr

謝謝，併爲這個定義不清的問題表示歉意。我在印象中（並且現在無法找到引用），通過在Web應用程序中創建線程，我們從IIS用於爲請求提供服務的相同線程池中分配線程。因此，如果我們增加併發用戶的數量，我們更有可能耗盡線程池，這基本上阻止IIS提供新的請求。現在如果2個線程池不一樣，這顯然不適用。它更有意義嗎？ – Pedro

a）ASP.NET和任務的線程池是相同的，但只要應用程序沒有超載，這不是問題。如果它超載，無論如何，無論使用什麼線程，都需要解決這個問題。並行性不會使超載（顯着）變得更糟。 b）您可以使用TaskScheduler API使用第二個線程池，但不能解決超載問題。沒有幫助。我應該解決的任何其他問題？ – usr

Web應用程序中的多線程（WCF/WebAPI）

回答

相關問題