我有一个运行在IIS 6上的应用程序，正在被数百个远程客户端进行各种请求，有些是长时间运行的，有些则不是。
在某些部署中，特别是目前， ASP .NET应用程序 – 请求执行计数器只是持续攀升，直到达到限制（5000），然后服务器停止接受请求。
在诊断问题时，这里有一些非常有趣的事实：
线程数在w3p进程和系统进程都很低（低于100）
整个系统的CPU很低
netstat -a（在任何状态）中列出的TCP连接总数为600，这是预期的，因为我们有大约600个远程客户端。
那么为什么在IIS中执行请求的时候，如果没有任何事情发生，一切似乎都开始并正确终止？
编辑
我想补充说，这些是使用IHttpAsyncHandler模式的asynchronous调用。 我相信这些没有超时。
“在某些部署上” – 这是什么意思？
简短的回答：因为你的工作线程被捆绑挂起，而不是超时。
如果是ASP.Net， 零售模式下的线程应该在120秒后超时。
因为他们不是，要么有严重的错误，要么在debugging模式下运行，即在你的configuration文件（machine或web.config）中设置<compilation debug="true"> 。
这不应该在生产Web服务器上设置。
如果情况并非如此，那么请debuggingDebugDiag 1.2，并在线程泄漏时使用它来评估应用程序的内存转储。 它应该能够显示线程堆栈的泄漏执行请求，并希望能帮助你理解和解决问题。
你说：
做各种各样的请求，有些是长时间运行的，有些则不是。
长时间运行的请求最终会终止你的服务器 如果你有很多这些，那么你将最终导致线程池耗尽，并达到允许的最大请求数。
如果这些长时间运行的请求是I / O绑定（但不是CPU绑定），例如调用其他Web服务或等待SQL操作完成，则考虑将这些页面转换为asynchronous页面：
ASP.NETasynchronous页面以及何时使用它们
邪恶的代码：ASP.NET 2.0中的asynchronous页面
在ASP.NET应用程序中执行asynchronous工作或任务
如果你使用ASP.NET MVC，那么你可以做同样的事情：
在ASP.NET MVC中使用asynchronous控制器