多線程的web應用程序

Question

我知道有很多情況下，最好多線程的應用程序，但 什麼時候最好多線程一個.net的web應用程序？

Answer 1

Web應用程序幾乎可以肯定已經由宿主環境（IIS等）多線程化。如果你的頁面是CPU限制的（並且想要使用多個內核），那麼可以說多線程是一個壞主意，因爲當你的系統處於負載下時，你已經在使用它們了。

它的時間它可能幫助是當你IO的約束;例如，您有一個需要與3個外部Web服務交談的網頁，與數據庫交談並編寫一個文件（全部不相關）。您可以在不同線程上並行執行這些操作（理想情況下使用內置的異步操作，以最大限度地提高完成端口的使用率），以縮短總體處理時間 - 所有操作都不會對本地CPU造成太大影響（這裏實際的延遲在網絡上）。

當然，在這種情況下，您也可以通過簡單地在Web應用程序中排隊工作，並讓單獨的服務將它們出列並處理它們來做得更好，但是不能立即響應調用者需要稍後檢查確認完成等）。

Answer 2

爲了從多線程中受益，您的應用程序必須執行大量可並行運行的工作。如果情況並非如此，多線程的開銷可能會帶來好處。

根據我的經驗，大多數Web應用程序都包含一些簡短的運行方法，因此除了託管環境已經提供的並行性之外，我會說很少從Web應用程序的各個部分中的多線程中受益。有可能會提供一些好處的例子，但我的猜測是它並不常見。

Answer 3

恕我直言，你應該避免在基於Web的應用程序中使用多線程。

也許多線程應用程序可以提高標準應用程序的性能（使用正確的設計），但是在Web應用程序中，您可能希望保持高吞吐量而不是速度。

，但如果你有幾個併發連接也許你可以使用並行線程沒有一個全球性的性能下降

Answer 4

ASP.NET已經能夠產卵幾個線程並行處理多個請求的，所以對於簡單的請求處理有當你需要手動產生另一個線程時，情況很少。不過，也有我所遇到這保證另一個線程創建了幾個常見的場景：

• 如果有可能需要一段時間，並且可以在平行於頁面處理的其餘部分運行一些操作，你可能會在那裏產生一個輔助線程。例如，如果有一個Web服務必須作爲請求的結果進行輪詢，則可能會在Page_Init中產生另一個線程，並檢查Page_PreRender中的結果（如果需要，等待）。儘管這仍然是個問題，但這是否會帶來性能上的好處 - 產生線程並不便宜，而且典型的Page_Init和Page_Prerender之間的時間無論如何都是以毫秒爲單位來衡量的。爲此保留一個線程池可能會更有效一些，而ASP.NET也有一些稱爲「異步頁面」的東西，可能更適合這種需求。
• 如果有一個您希望定期清理的資源池。例如，假設你正在使用一些帶有有限.NET綁定的奇怪DBMS，但沒有池化支持（這是我的情況）。在這種情況下，你可能要自己實現數據庫連接池，而這將需要一個「清理線程」，它就會醒來，比方說，一分鐘一次，並檢查是否有尚未被長期使用，而連接（和因此可以關閉）。

在ASP.NET中實現自己的線程時要記住的另一件事 - 如果ASP.NET在一段時間內一直處於非活動狀態，它喜歡殺死它的進程。因此，你不應該依賴你的線程永遠活着。它可能在任何時候被終止，你最好準備好。

Answer 5

多線程是這樣一種技術，以提供一個單一的過程與更多的處理時間，以允許它運行得更快。它有更多的線程，因此它消耗更多的CPU週期。 （如果有的話，可以從多個CPU中獲得）。對於桌面應用程序來說，這很有意義。但是，向Web用戶授予更多的CPU週期將會從同時請求請求的99個其他用戶那裏獲得相同的週期！從技術上講，這是一件壞事。

然而，Web應用程序可能使用其他的服務和進程正在使用多個線程。例如，數據庫不會爲連接到它們的每個用戶創建單獨的線程。它們將線程數量限制爲少數，將連接添加到連接池以加快使用率。只要有可用或彙集的連接，用戶就可以訪問數據庫。當數據庫用完連接時，用戶將不得不等待。

因此，基本上，多個線程的使用可以用於Web應用程序，以減少特定時刻的活動用戶數量！它允許系統與多個用戶共享資源，而不會使資源過載。相反，用戶在輪到他們之前必須排隊。

這不會是Web應用程序本身的多線程，而是Web應用程序使用的服務中的多線程。在這種情況下，它被用作限制，只允許少量線程處於活動狀態。