我们有一个生产系统，它是发布到 Azure 的 ASP.NET Web API(经典，而不是 .NET Core)应用程序。数据存储是Azure SQL Database，我们使用Entity Framework来访问数据。 API 具有中等负载，每秒 10-60 个请求，upper_90 延迟为 100-200 毫秒，这是我们案例中的目标延迟。不久前，我们注意到大约每 20-30 分钟我们的服务就会停止一次，并且延迟会跳至大约 5-10 秒。所有请求开始缓慢约一分钟，然后系统自行恢复。同时没有请求被丢弃，它们只是需要更长的时间来执行。很短的一段时间(通常是 1 分钟)。
我们开始在 HTTP 请求遥测 (Azure) 中看到以下图片:
我们还可以看到与 Azure SQL 数据库指标的相关性，例如 DTU(下降)和连接(增加):
我们分析了服务器，没有发现与主机(我们只有一台主机)CPU/内存使用率有任何相关性，它稳定在 20-30% CPU 使用率和 50% 内存使用率。
我们还有另一个遥测来源，它显示出相同的行为。我们的遥测测量 API 延迟和数据库指标，例如事件连接计数和池连接计数(ADO.NET 连接池):
有趣的是，每次系统停顿都伴随着池连接数量的增加。我们的测试表明，池中的连接越多，等待该池中的新连接以执行下一个数据库操作的时间就越长。我们分析了一些建议，但无法证明或反驳其中任何一个:
- ADO.NET 连接泄漏(我们所有的数据库访问都发生在 using 语句中，并具有正确的连接处理/返回池)
- 套接字/端口耗尽 - 无法正确跟踪该指标的遥测数据
- CPU/内存瓶颈 - 图表显示不存在
- DTU(数据库单元)瓶颈 - 图表显示不存在
目前，我们正在努力找出造成此行为的可能罪魁祸首。不幸的是，由于缺少遥测，我们无法识别导致该问题的变化，因此现在处理该问题的唯一方法是正确诊断它。当然，我们只能在永久负载下在生产中重现它(即使负载不高，例如每秒 10 个请求)。
导致此行为的可能原因是什么？诊断和解决该问题的正确方法是什么？
最佳答案
可能有多种原因:
问题可能出在您的应用程序代码中，创建一个临时环境并使用探查器工具遥测(即使用 YourKit .NET Profiler)重新运行您的测试 - 这将允许您检测最重的方法、最大的对象、最慢的数据库查询等。还可以使用 JMeter 对您的 API 进行负载测试。
我建议您尝试 Kudu Process API 来查看当前正在运行的进程的列表，并获取有关它们的更多信息，列出它们的 CPU 时间。
如何监控Azure应用服务中CPU使用情况的文章如下所示:
https://azure.microsoft.com/en-in/documentation/articles/web-sites-monitor/
https://azure.microsoft.com/en-in/documentation/articles/app-insights-web-monitor-performance/
关于entity-framework - 发布到 Azure Web App 的 ASP.NET Web API 中出现不可预测的 API 请求延迟峰值，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/58230706/