在我们的ASP.Net网站上,一些请求超时了。AppDynamics显示SQL存储过程调用只需要几秒钟就能返回结果,但是我们花费了100多秒在SNIReadSyncOverAsync上。有人知道这个方法是做什么的,为什么会花费那么长时间吗?我们没有使用EF,这在我能找到的每个问题/帖子中都被引用。谢谢提前。
更新
已经过了一段时间,虽然我们从未解决为什么所有时间都花在SNIReadSyncOverAsync上的问题,但我有几个想法。我认为在这种情况下,可能是特定版本的AppDynamics报告了在SQL调用上所花费的时间方式,但我没有真实的数据来支持我的猜测,只是根据我观察到的情况。我们最终停止看到花费在SNIReadSyncOverAsync上的时间,并且它转移到了查询本身超时。即使在同一个数据库中,相同的查询也可以在SSMS中立即运行,这仍然不太合理。
最终答案与ARITHABORT有关,导致我们的应用程序和SSMS使用了两个不同的执行计划(参见 https://dba.stackexchange.com/a/9841),这就解释了为什么我们无法在SSMS中重现超时问题。
解决了该问题后,我们能够确定该过程的一些部分需要进行调优,自此以后,我们没有再遇到未经说明的超时或SNIReadSyncOverAsync。
更新
已经过了一段时间,虽然我们从未解决为什么所有时间都花在SNIReadSyncOverAsync上的问题,但我有几个想法。我认为在这种情况下,可能是特定版本的AppDynamics报告了在SQL调用上所花费的时间方式,但我没有真实的数据来支持我的猜测,只是根据我观察到的情况。我们最终停止看到花费在SNIReadSyncOverAsync上的时间,并且它转移到了查询本身超时。即使在同一个数据库中,相同的查询也可以在SSMS中立即运行,这仍然不太合理。
最终答案与ARITHABORT有关,导致我们的应用程序和SSMS使用了两个不同的执行计划(参见 https://dba.stackexchange.com/a/9841),这就解释了为什么我们无法在SSMS中重现超时问题。
解决了该问题后,我们能够确定该过程的一些部分需要进行调优,自此以后,我们没有再遇到未经说明的超时或SNIReadSyncOverAsync。