我有一個從this question變異的異步/ await-on-ASP.NET的好處。ASP.NET異步/等待第2部分
我的理解是，異步與並行不是同一回事。所以，在Web服務器上，我想知道異步/等待對ASP.NET頁面帶來的好處。
IIS + ASP.NET是否已經非常善於爲請求分配線程，並且如果onen頁面正忙於等待資源，服務器將切換到處理另一個有效工作的請求？
ASP.NET中使用的池中的線程數量有限 - async是否更有效地使用它們？
正如Skeet先生在回答上述問題時指出的那樣，我們不是在討論阻塞UI線程。我們已經是多線程的，並且在所有請求的任務完成之前，Web響應無法完成，異步與否，對嗎？
我猜它歸結爲是這樣的：
有什麼好處異步讀取的資源（比如文件或數據庫的請求）在ASP.NET頁面與阻塞嗎？
如果一個頁面正忙着等待資源，服務器將切換到處理另一個有工作要求的請求？
我不這麼認爲。我會非常感謝如果是這樣的話。這在理論上是可能的，但非常複雜。
ASP.NET中使用的池的線程數量有限 - async是否更有效地使用它們？
是的，因爲當你await東西，該請求的線程立即返回到池。
我們已經是多線程的，並且在所有請求的任務完成之前，web響應無法完成，異步與否，對不對？
這是正確的。服務器場景中的async都是爲了消除線程池的壓力。
ASP.NET頁面中的資源異步讀取（比如文件或數據庫請求）與阻塞它有什麼好處？
絕對！
如果您阻止文件/服務調用/ db請求，那麼該線程將用於該操作的持續時間。如果你在await文件/服務調用/數據庫請求，那麼該線程立即返回到線程池。
其中一個（非常酷！）結果是您可以請求正在進行，並且在（a）等待某個操作時，有沒有線程正在處理該請求！零線程併發，如果你願意的話。
當操作完成後，該方法將在線程池（可能不同）的線程上執行await後繼續。
結論：async的縮放比線程更好，所以在服務器端肯定有好處。
更多信息：我自己的intro to async post和this awesome video。
從這個更近期的[回覆]（http://stackoverflow.com/a/30574578/1497596）你的好處：「如果你談論ASP.NET MVC與單個數據庫後端，那麼你（幾乎可以肯定）不會從'async'獲得任何可伸縮性，這是因爲IIS可以處理比單個SQL服務器（或其他經典的RDBMS）實例多得多的併發請求，但是如果你的後端更現代化 - 一個SQL服務器集羣，Azure SQL，NoSQL等 - 並且您的後端可以擴展，並且您的可伸縮性瓶頸是IIS，*然後*您可以從'async'獲得可伸縮性優勢。 – DavidRR 2017-05-17 20:35:03
你真的讀過Jon Skeet的回答嗎？他解釋了在ASP.NET中使用'async'的好處。 – svick 2012-08-02 14:15:09
@svick：謝謝你的閱讀。是的，我閱讀喬恩的答案，但在很多情況下，他說「這取決於」，我猜這是他*能給出的唯一答案。我想了解異步/等待對大容量Web服務器的線程影響。 – n8wrl 2012-08-02 14:21:34