什麼是SNIReadSyncOverAsync，爲什麼需要很長時間才能完成？

在我們的ASP.Net網站上，我們有一些請求超時。 AppDynamics顯示SQL過程調用在幾秒鐘內就會返回，但我們在SNIReadSyncOverAsync中花費了100多秒。什麼是SNIReadSyncOverAsync，爲什麼需要很長時間才能完成？

有沒有人知道這種方法是做什麼的，爲什麼會花費那麼多時間？我們沒有使用在每個問題/帖子中引用的EF，我已經能夠找到它。

在此先感謝

更新

它已經有一段時間，雖然我們未曾來決議，爲什麼所有的時間用在SNIReadSyncOverAsync正在度過的，我有幾個想法。

我認爲在這種情況下，它可能是特定版本的AppDynamics報告SQL調用花費的時間的方式，但我沒有真正的數據來支持這一點，只是我從我觀察到的。我們最終不再看到所報告的時間是在SNIReadSyncOverAsync中花費的時間，而是轉移到查詢本身超時。

這仍然沒有做很多，因爲相同的查詢會立即在同一個數據庫的SSMS上運行。

最終的答案最終與ARITHABORT有關，導致我們的應用程序和SSMS使用兩種不同的執行計劃（請參閱https://dba.stackexchange.com/a/9841），解釋了爲什麼我們無法使用SSMS重現超時。一旦我們解決了這個問題，我們就能夠確定需要調整的過程的一些部分，並且自那以後我們還沒有遇到不明原因的超時或SNIReadSyncOverAsync。

來源

2013-02-21 ryan.rousseau

MS的任何更新？ – too 2014-06-10 11:41:55

不幸的是，我們無法解決問題。更奇怪的是，更新版本的AppDynamics不再在SNIReadSyncOverAsync方法中顯示問題，而是在DbDataAdapter.Fill – 2014-07-02 21:54:05

不確定您是否已經解決了這個問題，但是：SNI是SQL Server網絡接口，並且在大多數等待SQL Server數據的ADO.NET完全調用堆棧中存在上述方法。這與高層實現是EF還是原始的ADO.NET或其他無關。

我不確定AppDynamics使用哪個度量或信號來捕獲存儲過程執行的完成情況，但是如果存儲過程完成得相對較快，但您可能會看到這種行爲，但從服務器傳輸查詢結果給你的客戶需要一段時間。

不知道更多關於您的基礎設施的信息，很難進一步提供幫助。如果問題仍然存在，我建議在SQL Server Management Studio中使用SET STATISTICS TIME ON和「包括客戶端統計信息」開啓相同的查詢。也許這些數字會給你一個關於數據傳輸是否確實是問題的想法。

來源

2013-05-14 12:33:59

我實際上已經有一個支持案例用MS打開。雖然沒有強有力的線索。如果我得到答案，我會更新。感謝SET STATISTICS的提示。 – 2013-06-14 15:41:17

您是否曾收到過Microsoft @ ryan.rousseau的有用回覆？ – 2016-07-27 16:47:42

就我的情況而言，正如Jouni所說的那樣，查詢結果的傳輸非常緩慢。我使用Automapper準備發送給客戶端的數據。所以，目前還不清楚究竟是什麼性質造成的負載，但要確保我已經削減了所有不需要在客戶端顯示的複合內容。（我最初需要一個集合在客戶端以網格顯示。）執行變得非常快。

來源

2017-02-03 13:12:58 alehro

什麼是SNIReadSyncOverAsync，爲什麼需要很長時間才能完成？

回答

相關問題