我正在使用ASP.NET 2.0，.NET 2.0 Framework和IIS 7.我看到“工作进程”选项下出现了一大堆“请求”。记录的状态似乎比Authenticate Request和Execute Request Handles更重要。
我在aspnet.config（32位路径和64位路径）中修改了C:\Windows\Microsoft.NET\Framework64\v2.0.50727以包含：
maxConcurrentRequestsPerCPU="50000"
maxConcurrentThreadsPerCPU="0"
requestQueueLimit="50000"
我在machine.config（32位和64位路径）中修改了C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG以包含：
autoConfig="false"
maxIoThreads="100"
maxWorkerThreads="100"
minIoThreads="50"
minWorkerThreads="50"
minFreeThreads="176"
minLocalRequestFreeThreads="152"
我仍然遇到这个问题。
该问题在工作进程队列中显示为大量请求。
发生此问题时，网站的当前连接数显示500。如果没有这个问题，我认为我没有看到超过500的并发连接。
随着请求阻止，Web应用程序会变慢。
当负载在两个池之间传播时，刷新应用程序池会解析一段时间（按预期方式）。
有问题的应用程序池FIXED REQUEST已设置为刷新50000。
注意：我相信.NET 3.5框架使用2.0框架appnet和机器配置文件。
服务器资源（CPU，RAM）未充分发挥潜力。
答案 0 :(得分：3)
我可以建议您查看Tess Ferrandez网站If It Is Broken, Fix It You Should上的资料。
您要做的是在请求队列中遇到大量请求时以及应用程序开始停止时，使用ADPlus捕获工作进程的转储。
一旦你抓住了这个转储，你就想把它加载到WinDBG + SOS中并开始追踪罪魁祸首。
Tess拥有一系列关于如何利用这些工具产生良好效果的实验室：
如果你能够，那么你也可以将一个探查器附加到应用程序（例如RedGate的Performance Profiler以尝试找出根本原因。
答案 1 :(得分：1)
关注知识库文章http://support.microsoft.com/kb/821268，如果您仍然面临此问题，请与我联系。
您还可以在IIS 7中尝试FREB跟踪。http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/
答案 2 :(得分：1)
结束将工作进程从1增加到2（Web园）。问题没有再发生，因为尽管正在使用会议，但在一个月内没有关于最终用户会话问题的报告。
编辑添加：
具体问题与生成非常大的CSV报告有关，这些报告在工作进程服务器端处理，而不是错误，只是它的工作方式。 HTML报告很好，XML转换是通过客户端传递的。
工作进程的分离解决了问题，直到服务器端xml转换为csv文件创建可以传递给添加进程，因此消除了来自其他用户的任何影响。在尝试创建CSV报告时，只需要达到我们正在使用的文件大小/行数。