IIS 7工作进程瓶颈，应用程序池ASP.NET 3.5下有大量等待请求+ 2.0
我正在使用 ASP.NET 2.0、.NET 2.0 Framework 和 IIS 7。我看到“工作进程”选项下出现大量“请求”。记录的状态似乎是验证请求和执行请求处理比其他任何事情都重要。
我修改了 C:\Windows\Microsoft.NET\Framework64\v2.0.50727 （32 位路径和 64 位路径）中的 aspnet.config 以包括：
maxConcurrentRequestsPerCPU="50000"
maxConcurrentThreadsPerCPU="0"
requestQueueLimit="50000"
我已修改c:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG 中的 machine.config （32 位和 64 位路径）包括：
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）未得到充分利用。
I am using ASP.NET 2.0, .NET 2.0 Framework, and IIS 7. I am seeing a large queue of "requests" appear under the "worker process" option. State recorded appear to be Authenticate Request and Execute Request Handles more than anything else.
I have amended aspnet.config in C:\Windows\Microsoft.NET\Framework64\v2.0.50727 (32 bit path and 64 bit path) to include:
maxConcurrentRequestsPerCPU="50000"
maxConcurrentThreadsPerCPU="0"
requestQueueLimit="50000"
I have amended machine.config in C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG (32-bit and 64-bit path) to include:
autoConfig="false"
maxIoThreads="100"
maxWorkerThreads="100"
minIoThreads="50"
minWorkerThreads="50"
minFreeThreads="176"
minLocalRequestFreeThreads="152"
Still I get this issue.
The issue manifests itself as a large number of requests in the Worker Process queue.
The number of current connections to the website display 500 when this issue occurs. I don't think I have seen concurrent connections over 500 without this issue occurring.
The web application slows as the requests block.
Refreshing the application pool resolves for a while (as expected) as the load is spread between the two pools.
The application pool in question FIXED REQUEST have been set to refresh on 50000.
Note: .NET 3.5 framework uses 2.0 framework appnet and machine configuration files, I believe.
Server resources (CPU, RAM) are not used to the full potential.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我可以建议您看一下 Tess Ferrandez 网站上的材料如果它坏了，你应该修复它< /a>.
您想要做的是，当您在请求队列中遇到大量请求以及应用程序开始停止时，使用 ADPlus 捕获工作进程的转储。
一旦你抓取了这个转储，你需要将其加载到 WinDBG+SOS 中并开始追踪罪魁祸首。
Tess 有一系列关于如何利用这些工具取得巨大效果的实验：
如果可以的话，您还可以将分析器附加到应用程序（例如 RedGate 的 性能分析器尝试发现根本原因。
Can I suggest you take a look at the materials on Tess Ferrandez's site If It Is Broken, Fix It You Should.
What you want to be doing is capturing a dump of the worker process using ADPlus at the time you experience a high number of requests in the request queue and when the app starts to grind to a halt.
Once you grabbed this dump you want to load this into WinDBG+SOS and start tracking down the culprit.
Tess has a great series of labs about how to utilise these tools to great effect:
If you are able to, then you could also attach a profiler to the application (such as RedGate's Performance Profiler to try and discover the root cause.
请按照知识库文章 http://support.microsoft.com/kb/821268 进行操作，如果出现以下情况，请更新我您仍然面临这个问题。
您还可以在 IIS 7 中尝试 FREB 跟踪。 http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/
Follow the KB article http://support.microsoft.com/kb/821268 and update me if you are still facing the issue.
You can also try FREB tracing in IIS 7. http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/
最终将工作进程从 1 个增加到 2 个（网络花园）。尽管我们正在使用会话，但问题并未再次发生，但在一个月的时间里，最终用户没有收到有关会话问题的报告。
编辑添加：
具体问题与生成非常大的 CSV 报告有关，该报告在工作进程服务器端进行处理，而不是错误，只是它的工作方式。 HTML 报告很好，XML 转换是在客户端传递的。
工作进程的分离解决了这个问题，直到服务器端 xml 转换为 csv 文件创建可以传递到添加进程，从而消除其他用户的任何影响。只是取决于我们在尝试创建 CSV 报告时所使用的文件大小/行数。
Ended up increasing the worker processes from 1 to 2 (web garden). Issue has not reoccurred since although were are using sessions but over the course of a month there have been no reports of session problems from end users.
EDITED TO ADD:
The specific issue was related to the generation of a extremely large CSV reports which are processed on the worker process server side, not a bug , just the way it works. HTML reports are fine, the XML transform is passed client side.
The separation of worker processes resolved the issues until the sever side xml transform to csv file creation can be passed to an addition process therefore removing any influence from other users. Was simply down to the size of the files / number of rows we were working with when trying to create CSV reports.