这里到底发生了什么？实际调用需要 8000 毫秒，但实际 DB 调用仅需要 <100 毫秒。这是负载测试的结果，在 Azure 中的 Web 应用程序上峰值约为 100 req/s。我尝试了横向扩展和向上扩展，但性能仍然相同。该调用是异步完成的，在早期，分析器对于此类请求不是很准确，但现在已经是 2017 年了……
那么，谁能告诉我它在哪里或者在等待什么？探查器跟踪中没有其他热路径或长调用，但是，整个请求中还有其他 DB 和 REST 调用，并且它们也是异步完成的(并且使用 wait 而不是 .Result 正确完成)。
也没有复杂的方法，但主要是外部异步调用。线程池耗尽？我们正在使用 ASPNET.CORE 和 netframework451
非常感谢任何见解。
最佳答案
在我看来，这是正确的事情。我猜你可能对await理解不太清楚。
来自 azure article .
等待 (AWAIT_TIME)
AWAIT_TIME 表示代码正在等待另一个任务完成。这通常发生在 C# 的“await”语句中。当代码执行 C#“等待”时，线程展开并将控制权返回给线程池，并且没有线程被阻止等待“等待”完成。 但是，从逻辑上讲，执行等待的线程被“阻塞”，等待操作完成。 AWAIT_TIME表示等待任务完成的阻塞时间。
所以你的代码仍然被阻塞等待异步调用完成，但是会释放线程来做其他事情。
关于c# - Application Insights Profiler 和 "AWAIT_TIME"，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46551913/