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