我試圖弄清楚在ASP.NET網站中使用ThreadPools是否好。有很多關於此的討論，但很難找到一個授權來源。用於加速網站的ThreadPools
我建立在用戶填寫表單並按下發送按鈕一個網站，這會觸發發送郵件。我的問題是我的郵件供應商的API很慢（100ms到12s），這對於應用程序的響應速度並不好。
這是一個好主意？：
ThreadPool.QueueUserWorkItem(e =>
EmailFactory.BuildBuyerEmailValidationEmail(client).Send()
);
的形式每天使用約100-200倍。
我想避免創建隊列，因爲這會增加應用程序的複雜性。
這對我來說看起來完全沒問題。線程池包含每個處理器250個線程，因此即使這種形式將提交一分鐘的50倍，它也沒有任何問題，因爲那時只有十線程將並行
有兩種可能出現的問題： 1）IIS可以應用程序域重裝（線程池線程） 2）下的線程池高壓實際工作中殺死後臺線程可以大大晚於正常調度（達到最大線程數時，該項目是在內存中的隊列持續，直到有可用線程）
但似乎線程池完全適合你的情況（發送電子郵件） - 你不需要完美的可靠性。
合作爲什麼不使用Message Queue完成這個？基本上，您會將請求放入隊列中，稍後可以處理該請求 - 該站點保持良好且響應良好，並且您有一個旨在保證處理的機制。
另一種選擇是設置處理所有電子郵件路由的Web服務（如WCF）。然後，您可以將服務方法配置爲單向調用，以便當用戶單擊該按鈕時，它將請求發送到web服務，並立即返回到頁面，因爲它不會等待Web服務進行處理。海事組織我會避免嘗試直接與IIS中的線程一起工作，並讓它以所需的方式管理線程。