我们遇到了IIS和Azure的一个非常严重的问题。不确定这是IIS端还是我们的自定义代码端。
我参与了两个在Azure（站点A和站点B）中运行的网站。 （标准WebRoles，ASP.NET MVC3）。这两个网站的架构完全不同，彼此无关，但在类似情况下两者都表现出相似的行为。
站点A在启用会话状态的情况下运行。会话存储在SQL Azure数据库中。对站点A的大多数调用都是通过指向SQL Azure数据库的ASP.NET SQL成员资格提供程序来保护的
站点B也在启用会话状态的情况下运行。会话存储在Azure AppFabric缓存中。站点B还有一个http处理程序，可与AppFabric Cache和Azure表存储进行通信。
问题开始但在关键Azure资源（如SQL Azure或缓存）变得非常慢时无法恢复。当这些资源变得非常慢并且每个请求的处理时间超过一分钟时，Azure的负载均衡器会终止这些连接，但Web角色上的IIS不会清除/从其活动队列中删除这些请求。
因此，当SQL Azure或AppFabric Cache非常慢时，问题不在于网站没有响应。最大的问题是，当SQL Azure或AppFabric Cache恢复并开始正常工作时，网站无法恢复。请求位于“活动请求”列表中，并且不会长时间（小时？）消失。坦率地说，我不知道他们坐了多长时间，因为我们尽快重启这些服务器。由于Azure资源偶尔会出现间歇性问题，并且由于到两个站点的流量非常高，因此两个站点都会在非清算请求的重压下迅速陷入困境。 IIS队列填满，直到有人进入并重新启动应用程序池，这些站点不可用。
答案 0 :(得分：2)
IIS保持请求“活着”这一事实非常奇怪。您是否尝试将请求超时配置为少于60秒？执行此操作将使IIS处于控制中以终止请求，而不是让负载均衡器关闭连接：
<httpRuntime executionTimeout="50" />
注意：这仅在Debug = false
时有效答案 1 :(得分：0)
我遇到了类似的问题，IIS请求会持续很长时间。我花了很长时间试图弄清楚为什么IIS没有杀死它们。我试过Sandrino Di Mattia的解决方案，还有其他人，其中没有一个对我有用。
事实证明，IIS并未查杀请求，因为它们仍处于活动状态。在某些情况下，客户端浏览器会打开一个连接并永远保持它。我会查看浏览器的网络调试器（Firebug，Webkit检查器等）并查看刚刚坐在那里的请求。据我所知，他们正在响应Keepalive，因此IIS和负载均衡器会保持连接和请求处于活动状态。最终的解决方案是让浏览器不这样做。
它可能与您的问题无关，但在我的特定情况下，问题是<video>标记。当一个<video>标签指向一个大文件时，他们会立即打开一个连接并保持它直到视频播放，这可能永远不会（我们关闭了自动播放）。解决方案是在我们准备播放视频之前不创建<video>标签。
另外，有没有办法知道Azure负载均衡器已经杀死了请求？我知道看到活动的唯一方法是通过IIS管理控制台发送请求。