我们在 Azure 中的 VM 上运行了一个生产 Web 应用，我们看到相对简单的 ASP.NET Web API 请求需要 2-5 秒，而它们应该在大约 50 毫秒内得到处理。 我可以通过请求详细信息页面来常规(10 次中的 8 次)对网站进行复制。 发出 48 个请求的详细信息页面，其中 12 个是 Web API 调用。 对静态内容的请求在 100 毫秒内得到一致的服务，通常低于 50 毫秒。我们已经经历了许多诊断步骤，但没有成功。
采取的诊断步骤
受监视的性能计数器。 我们设置了一个数据收集器集来检查：高 CPU 利用率、高网络 I/O、高磁盘活动、高内存利用率、高垃圾回收率/时间、高踏步/锁争用率、高异常率、高管道实例计数。 没有什么突出的。 事实上，CPU 平均低于 5%，在有问题的呼叫期间不超过 10%。
对 API 调用启用了拦截。 我们的 Web API 是围绕 API 调用的非常薄的包装器。 我们在 API 调用上启用了 Unity 拦截，以便深入了解 API 为请求提供服务所需的时间。 这表示呼叫将在 15 毫秒内得到服务。
已启用慢速命令拦截器。 我们启用了自定义实体框架慢速命令拦截器来监视执行时间超过 1 秒的 SQL。 这偶尔会标记慢速命令，但它与慢速 Web API 请求无关。 奇怪的是，慢速命令是简单的命令，在 SSMS 中的执行时间为 20 毫秒。
已检查 Azure SQL 数据库。 由于慢速命令拦截器显示慢速命令，因此我们检查了 Azure SQL 数据库，以确保没有查询被标记为性能不佳，并且我们没有达到 DTU 阈值。 没有显示查询需要几秒钟才能执行。 事实上，即使是被标记的查询也会在不到 200 毫秒的时间内执行。 数据库远未达到 DTU 阈值或配额。 我们将其中一个慢速命令放入 SSMS，并检查了成本和执行时间。 成本为 0.006，平均执行时间为 20 毫秒。
已启用 IIS 失败请求跟踪。 我们启用了 IIS 失败请求跟踪，并将时间阈值设置为 2 秒。 跟踪会捕获慢速请求，但跟踪日志不会显示需要很长时间的请求的任何部分。 在每种情况下，只有一两个事件的时间高于 0 毫秒。 两个有时间的事件的时间大约是30毫秒和350毫秒。
禁用压缩。 我们打开了静态内容压缩。 我们禁用它只是为了排除它。 没有效果。
已删除第三方AV/防火墙。我们安装了第三方AV/防火墙。 由于我们看到可能存在一些通信问题(查询和请求速度慢)的迹象，因此我们暂时将其删除以排除任何干扰。
已检查 Azure 主机。 我们查看了 Azure 主机性能计数器以获得高资源利用率。 一切都很低。
服务器/应用信息
服务器是 DS2v2，具有 2 个内核和 7 GB 内存。 它运行的是Windows Server 2016数据中心。 CPU 为 E5-2673v3。 Web 应用运行的是 .NET 4.6.2。 我们不会在 Web API 之外大量使用 ASP.NET。 我们不依赖于会话状态。 页面是普通的旧HTML5，是真正的无状态。
我们在运行此应用程序相同版本的其他 Web 服务器上没有看到此问题。 我们看到，从机器内部运行的浏览器实例发出请求的缓慢行为与来自外部的请求相同。
总结
IIS和我们的API之间似乎有一些东西正在减慢处理速度，但到目前为止采取的诊断步骤没有显示任何内容。 关于如何定位问题的任何建议？
在回答准确答案之前，我必须知道您如何检索数据？ 例如，在某些情况下，我们只需要用户的 ID 即可进一步移动应用程序。 因此，请确保仅调用对特定操作至关重要的列。 一个简单的场景，需要在应用程序中显示用户的用户名，你应该选择：SELECT u.Username FROM AspNetUsers u Where u.Id = @ID
而不是：
SELECT * FROM AspNetUsers WHERE Id = @ID
我希望我的回答有所帮助。祝你好运