是否異步並等待提高ASP.Net應用程序的性能

我最近閱讀了一篇關於c#-5和新的&很好的異步編程功能的文章。我發現它在Windows應用程序中起作用。問題來了，如果這個功能可以提高ASP.Net性能？是否異步並等待提高ASP.Net應用程序的性能

考慮這兩psudo代碼：

public T GetData() 
{ 
    var d = GetSomeData(); 
    return d; 
}

和

public async T GetData2() 
{ 
    var d = await GetSomeData(); 
    return d; 
}

在擁有一個ASP.Net器件的應用是兩個代碼的區別？

感謝

2012-03-26 Arian

那麼開始你的第二段代碼將返回Task<T>而不是T。最終的答案是「取決於」。

如果您的頁面需要訪問多個數據源，那麼或可以更簡單地並行訪問這些源，並僅在必要時使用每次訪問的結果。因此，例如，您可能想要開始作爲頁面處理的第一部分進行長時間運行的數據提取，然後只需要最後的結果。顯然可以在不使用異步/等待的情況下執行此操作，但當語言幫助您時，這樣做更簡單。

此外，異步可用於處理大量長時間運行的請求（如果大多數請求在很長時間內都會空閒） - 例如在長輪詢場景中。在某些情況下，我可以看到異步功能被用作SignalR的替代方法。

異步服務器端的好處比客戶端更難以固定，因爲有不同它幫助的方式 - 而「避免在UI線程上工作」這一方如此明顯，很容易看到好處。

不要忘記，服務器端編碼可能比前端更多。根據我的經驗，異步在實現RPC服務時最有用，尤其是那些與多個RPC服務交互的RPC服務。

正如Pasi說的那樣，它只是語法糖 - 但我相信它足夠甜，它可能會使正確的異步處理變得可行，而這只是太多的努力和複雜性。

2012-03-26 05:33:43

由於代碼在服務器上執行，用戶仍然要等待響應，問題是這樣 - 確實異步調用去比同步調用更快。

那麼，這主要取決於服務器的實現。對於IIS和多個用戶，每個用戶會產生太多線程（即使沒有異步），異步效率也會很低。但是，如果用戶數量少，它應該更快。

看到的一種方法是嘗試。

2012-03-26 05:29:24

不可以。這些純粹是語法糖，只需編寫簡單的代碼並在修復錯誤時簡單閱讀代碼即可輕鬆完成作爲程序員的工作。

它確實允許更簡單的方法來加載數據而不會阻塞用戶界面，所以在某種意義上是這樣，但並非如此。

2012-03-26 05:30:30

在「異步太困難了;讓我們爲每個請求使用一個線程」和「異步很容易 - 讓我們更高效地完成任務」之間的區別時，它會*產生影響。僅僅因爲它*都可以手動完成並不意味着它不能用於對性能產生影響。 – 2012-03-26 05:39:11

定義「表現」。

最終，應用程序將完成與其同步完成的相同工作量，只是異步版本中的調用線程將等待該操作在另一個上完成，而在同步模型中它是執行任務的同一個線程。

最終在這兩種情況下，客戶端在等待Web服務器響應之前都會等待相同的時間，因此不會注意到性能上的任何差異。

如果Web請求正在通過異步處理程序處理，那麼響應仍然需要相同的時間才能返回 - 但是，您可以降低線程池的壓力，使Web服務器本身更加接受請求 - see this other SO以瞭解更多詳情。

2012-03-26 05:32:10

如果您需要做多件事情，那麼這隻會提高性能，這些都可以在不需要任何其他信息的情況下完成。否則，你可以按順序進行。

就你的例子而言，答案是否定的。無論如何，頁面都需要等待每個頁面。

2012-03-26 05:34:14

假設您需要做的事情是等待最多5分鐘的聊天消息。你是否希望每一個請求佔用這麼長的時間？您希望在單個服務器上支持多少用戶？（想想一個長輪詢AJAX請求。） – 2012-03-26 05:53:01

不會輪詢聊天消息只需要客戶端輪詢，檢查消息，然後返回是或否。我看不到線程會如何等待它。我會以計時器爲基礎。除非我誤解了你的問題？ – 2012-03-26 06:22:02

長輪詢的要點是發出一個請求，可以在有數據時立即返回*，因此客戶端不需要每隔30秒左右輪詢一次。您可以獲得更快的反饋，更少的請求，但是您需要能夠處理非常長的持續連接。 – 2012-03-26 06:27:06

回答