異步和web請求處理

Question

我一直在閱讀更多關於C＃的新異步關鍵字和它在.NET 4.5中的支持，我正在尋找一些幫助來思考它是'正確的方式'。

我的第一個想法是，我可以通過不需要等待的事情（比如發送電子郵件，記錄日誌等等）異步地提高我網站的響應速度。這是我想要開火併忘記的事情，而不是讓我的客戶等待。

但後來我讀了SQL here的新異步版本，我感到困惑。從數據庫中讀取數據是我必須等待的 - 我需要這些數據 - 並且在完成之前我無法繼續。這是否意味着我不能使用它？

或者，這是否意味着我通過不阻止SQL調用使得我的請求處理更友善？

Answer 1

這些事情的答案總是「取決於」。

在您的特定情況下，如果您正在向IIS提供請求，那麼您絕對要儘可能利用此功能，但必須以有利於IIS的方式進行操作。

例如，當一個客戶端向一個ASP.NET頁面發出請求時（我認爲是這種情況，並且詢問有關IIS和.NET的問題，這實際上是唯一的選擇），服務器啓動了一個線程處理您的請求。當然，如果有很多請求，那麼它會佔用很多線程，可能比服務器可以處理的多，這意味着一些請求必須等待而其他進程正在處理。

如果在你的線程中（這是阻塞服務器上的其他線程），你必須等待其他工作其他地方，那麼在等待響應（來自網絡服務，數據庫等）。最好讓服務器返回線程，然後告訴服務器何時您準備再次工作並提供響應。

爲此，ASP.NET有機制讓服務器知道它可以在等待響應時執行其他操作。 （ASP.NET MVC）有asynchronous pages（我個人覺得有些複雜），而ASP.NET MVC有asynchronous methods in version 4（這很適合Task-based asynchronous pattern）。

這就是說，它應該指出的是，如果你有一個具有在等待響應獨立完成其他的工作，那麼就沒有理由產生線程返回到服務器，只是做你的工作，當你已經達到了無法進一步發展的地步，收回控制權。

不管你做什麼，不要等待任務的結果;您在阻止服務器使用該線程進行其他用途時，您無所事事，但正在等待。這可能是可擴展性的最大障礙，並且學習不需要佔用服務器資源是編寫高度可擴展系統的關鍵之一。