Application Insights Profiler 和“AWAIT_TIME”

Question

这里到底发生了什么？实际调用需要 8000 毫秒，但实际 DB 调用只需要 <100 毫秒。这是负载测试的结果，该测试在 Azure 中的 Web 应用程序上达到了大约 100 req/s 的峰值。我尝试横向扩展和纵向扩展，但性能仍然相同。调用是异步完成的，在早期，分析器对这种请求不是很准确，但现在是 2017 年......

那么，谁能告诉我它在哪里或在等待什么？探查器跟踪中没有其他热路径或长调用，但是，整个请求中还有其他 DB 和 REST 调用，它们也是异步完成的（使用 await 而不是 .Result 正确完成）。

也没有复杂的方法，但主要是外部异步调用。线程池耗尽？我们将 ASPNET.CORE 与 networkframework451 一起使用

非常感谢任何见解。

Answer 1

在我看来，这是正确的事情。我猜你可能不太清楚await。

出自蔚蓝文章。

等待 (AWAIT_TIME)

AWAIT_TIME 指示代码正在等待另一个任务完成。这通常发生在 C# 的“await”语句中。当代码执行 C#“await”时，线程展开并将控制权返回给线程池，并且没有线程被阻止等待“await”完成。然而，从逻辑上讲，执行等待的线程被“阻塞”，等待操作完成。AWAIT_TIME表示等待任务完成的阻塞时间。

因此，您的代码仍然被阻塞等待异步调用完成，但会释放线程去做其他事情。