我已經繼承了一個MVC Web應用程序，它使用ADO.NET之上的Dapper在Controller動作方法中進行數據庫調用。這都是非常標準的東西 - 並不是很多控制器都是async，所有的數據庫調用都通過完全同步的repository。讓我的控制器DB調用異步與否
我正在將其轉移到Azure，並將SQL Azure用於數據庫後端。我期望加載是相當標準的 - 比如每分鐘500到1000次點擊。
所以，我想知道，我應該犁通過這個代碼，使我所有的數據庫調用異步，以便我可以await然後在控制器。這樣做會釋放我的線程來滿足其他請求，但我真的想知道是否我會注意到任何改進。
我知道，以前它的been noted，如果你有一個單一的數據庫服務器（就像我這樣做），那麼你不會看到太多的改善，因爲瓶頸都在數據庫上。但是，SQL Azure是一個稍微不同的野獸，和Azure的狀態
您只使用異步技術來訪問Azure的服務，如SQL數據庫 source所以
良好實踐的要求 - 這是值得的努力？
坦率地說，在這裏不可能給出任何明確的答案。正如Azure所述，最佳做法是對I/O綁定操作使用異步，包括查詢遠程數據庫等。如果你今天從頭開始這個應用程序，我肯定會告訴你使用數據庫調用的異步。
但是，這不是一個新的應用程序，它聽起來像使用異步將需要相當多的手術在這一點上。根據你得到的負擔，你可能不會看到任何工作收益，但你也可能看到很大的收益。我的建議是從小處着手。我會挑選出一些更長時間運行的查詢或嚴重依賴數據庫的操作，並從這些操作開始。這樣，你可以引入一些異步並判斷是否值得進一步追求。而且，由於這些可能會成爲您的應用程序的瓶頸，無論如何，您將獲得最有潛力的異步優勢。
您添加的任何新功能應該從一開始就是異步的，然後，只要有時間和傾向，就可以在轉換整個應用程序時慢慢工作。
我學到的東西（並通過測試驗證）是，對於相對較長的SQL調用，您看不到很大的改進。但是你會看到併發的短SQL和非SQL相關響應的改進。這是因爲初始化線程的成本很高。因此，重用正在等待SQL的休眠線程可以提高性能。
使用異步還可以保護您避免在IIS中設置「每處理器線程數限制」設置。發生這種情況時，您的請求會排隊。我們已經嘗試增加默認值25.這確實提高了高負載下的性能，但是通過將所有控制器更改爲異步，我們看到了更好的改進。
所以我想你的問題的答案是，這取決於。如果除了SQL調用之外，還有大量的併發請求，那麼這些併發請求的響應時間應該會有明顯的改善。但是在相對較長的SQL調用中你不會看到很多改進。