IIS“SendResponse”状态的请求长时间滞留; IIS 7.5 / ASP.NET 4.0 Web应用程序缓慢

我有一组非常强大，利用率很低的服务器，它们运行着几台装有Windows Server 2008 R2和IIS 7.5的虚拟机。

问题：有时请求需要很长时间才能处理。用户看到他们的浏览器在旋转，显然没有得到任何来自IIS的响应。

一些统计信息和尝试解决：

服务器（主机和虚拟机）上的负载可以忽略不计。 CPU永远不会超过5％，有10多GB的可用RAM，一切都通过MPIO连接到一个快速的SAN。
我每秒获得30到50个请求，dynamic和静态内容的混合，只有GET和POST。大多数命中被caching（命中率为80％），所以fabric / SAN / IO上的负载几乎没有。
在主机和虚拟机上禁用TCP卸载，无论是在networking适配器上还是通过禁用TCP烟囱
Web应用程序正在ASP.NET 4.0集成模式下运行。他们不会长时间打电话给第三方Web服务或类似的。
我已经尝试了processModel autoConfig，以及设置maxWorkerThreads，maxConnections，maxIOThreads等非常高的数字没有区别。
数据库查询都在不到1秒内完成。我整理了一整天，并没有捕获一个需要更长时间的单个查询。
我看了大量的性能监控计数器; ASP.NET队列和应用程序队列总是空的，没有任何东西看起来排在队列之外（考虑到服务器根本没有出汗，这是没有任何意义的）
我已经确定使用appcmd列表请求，有时候会在IIS的“SendResponse”阶段中请求“滞留”20-60秒。 这是我迄今为止唯一能够find的东西，这对于我们为什么看到用户在浏览时陷入困境是有道理的。请注意，尽pipe大多数请求都得到了快速处理，但看起来就像来自不同应用程序池的随机请求在此处停滞不前。

任何想法还有什么我可以看看？什么会导致请求卡在IIS的“SendResponse”阶段？

你有没有find解决办法？我很久以前就看到了同样的事情，在JSWeb，PNG和GIF等静态内容被阻塞在“IIS Web Core”模块中的“SendResponse”状态的时候。我与IIS 7 / ASP.NET 4.0处于相同的情况。我用这个Microsoft.Web.Administration代码监视这些，而不是appcmd。

更新：在一些进一步的研究，我提出了一个可能性是它可能是一个丢弃的networking连接。在此线程中，该人员在他的IIS日志中报告了1236的Win32状态代码，即“networking连接被本地系统中止”。我不确定，但是如果这意味着请求者取消了请求，或者Web服务器中止了请求。可以想象，请求者可能会导航到您的网站上的所有这些HTTP请求页面内容（图像，JS等）已经完成，这可能会中止所有未决的请求到Web服务器（即他点击页面上的链接当它第一次呈现）。我在我的IIS日志中发现了1236个Win32状态码（主要是用于静态内容，比如GIF，PNG和JS，其中有些与ASPX页面绑定），但是，我不确定这些是否是相同的请求看到卡在“SendResponse”状态。

这通常是由于移动设备在慢速数据连接下载大型资产文件。当我说“大”我的意思是相对于连接的速度。

这些请求不是“挂起”的，它们只是需要很长时间，因为它们依赖于用户的networking速度。如果用户断开连接，请求将被丢弃，所以他们可能耐心地等待页面加载。

检查“悬挂”请求旁边列出的IP并查找它们，您可能会发现它们属于移动电话运营商。