30

在我们的 ASP.Net 网站上，我们遇到了一些请求超时。AppDynamics 显示 SQL 过程调用在几秒钟内返回，但我们在 SNIReadSyncOverAsync 中花费了 100 多秒。

有谁知道这种方法是/做什么以及为什么要花那么多时间？我们没有使用我能够找到的每个问题/帖子中都引用的 EF。

提前致谢

更新

已经有一段时间了，虽然我们从未就为什么所有时间都花在 SNIReadSyncOverAsync 上达成一致，但我有一些想法。

我认为在这种情况下，可能是特定版本的 AppDynamics 报告了在 SQL 调用上花费的时间的方式，但我没有真实的数据来支持它，这只是我观察到的猜测。我们最终不再看到报告为 SNIReadSyncOverAsync 所花费的时间，而是转向查询本身超时。

这仍然没有多大意义，因为相同的查询会立即在 SSMS 中的同一数据库上运行。

最终答案最终与 ARITHABORT 相关，导致我们的应用程序和 SSMS 使用两个不同的执行计划（请参阅https://dba.stackexchange.com/a/9841），解释了为什么我们无法使用 SSMS 重现超时。

一旦我们解决了这个问题，我们就能够确定需要调整的过程的几个部分，并且我们没有遇到无法解释的超时或 SNIReadSyncOverAsync 自那以后。

4

3 回答 3

16

不确定您是否已经解决了这个问题，但是：SNI 是 SQL Server 网络接口，并且上述方法存在于大多数等待来自 SQL Server 数据的 ADO.NET 完整调用堆栈中。这与更高级别的实现是 EF、原始 ADO.NET 还是其他无关。

我不确定 AppDynamics 使用哪个指标或信号来捕获存储过程执行的完成，但是如果您的存储过程完成相对较快，您可能会看到这种行为，但是将查询结果从服务器传输到客户端需要一会儿。

如果不了解您的基础架构的更多信息，就很难进一步提供帮助。如果问题仍然存在，我建议在 SQL Server Management Studio 中运行相同的查询，同时打开 SET STATISTICS TIME 并打开“包括客户端统计信息”。也许这些数字会让您了解数据传输是否真的是问题所在。

于 2013-05-14T12:33:59.397 回答
1

就我而言，正如 Jouni 所提到的，查询结果的传输速度确实很慢。我使用 Automapper 准备发送给客户端的数据。因此，目前尚不清楚究竟是什么属性导致了负载，但要确保我已经删除了所有不需要在客户端显示的复合属性。（我最初需要一个集合在客户端的网格中显示。）执行变得非常快。

于 2017-02-03T13:12:58.083 回答
0

我遇到过类似的问题——事实证明，如果你从大选择中提前中断，SqlDataReader.Dispose 可能会卡住很长时间。

见：https ://github.com/dotnet/corefx/issues/29181

于 2018-04-18T16:08:53.663 回答