在我们的ASP.Net网站上，我们有一些请求超时。 AppDynamics显示SQL过程调用在几秒钟内返回，但我们在SNIReadSyncOverAsync中花费了100多秒。
有谁知道这种方法是什么/做什么以及为什么花费这么多时间？我们没有使用在我能够找到的每个问题/帖子中引用的EF。
提前致谢
更新
已经有一段时间了，虽然我们从来没有解决为什么所有的时间都花在了SNIReadSyncOverAsync上，但我有一些想法。
我认为在这种情况下，它可能是特定版本的AppDynamics报告SQL调用花费的时间的方式，但我没有真正的数据支持这一点，只是我从我观察到的猜测。我们最终停止看到报告的时间在SNIReadSyncOverAsync中花费，并且它转移到查询本身超时。
由于相同的查询会在同一数据库中的SSMS中立即运行，因此仍然没有做太多。
最终答案最终与ARITHABORT相关，导致我们的应用程序和SSMS使用两个不同的执行计划（请参阅https://dba.stackexchange.com/a/9841），解释了为什么我们无法使用SSMS重现超时。
一旦我们解决了这个问题，我们就能够确定需要调整的过程的一些部分，并且我们没有遇到无法解释的超时或SNIReadSyncOverAsync，因此。
答案 0 :(得分：13)
不确定您是否已经解决了这个问题，但是：SNI是SQL Server网络接口，并且大多数ADO.NET完整调用堆栈中都存在提到的方法，这些堆栈等待来自SQL Server的数据。无论更高级别的实现是EF，原始ADO.NET还是其他任何内容，都是如此。
我不确定AppDynamics使用哪个度量标准或信号来捕获存储过程执行的完成，但如果存储过程完成相对较快，但是从服务器传输查询结果，则可能会看到这种行为你的客户需要一段时间。
在不了解您的基础架构的情况下，很难进一步提供帮助。如果问题仍然存在，我建议在SQL Server Management Studio中使用SET STATISTICS TIME ON运行相同的查询，并打开“包含客户端统计信息”。也许这些数字可以让您了解数据传输是否真的是问题。
答案 1 :(得分：1)
就我而言，正如Jouni所提到的那样，查询结果传输速度非常慢。我使用Automapper准备发送给客户端的数据。因此，目前尚不清楚究竟是什么属性造成了负担，但我确定已经切断了我不需要在客户端展示的所有复合材料。 （我最初需要一个在客户端以网格显示的集合。）执行变得非常快。
答案 2 :(得分：0)
我遇到过类似的问题 - 事实证明，如果你从大选中提前中断，SqlDataReader.Dispose可能会被卡住很长时间。