IIS 7 workflow bottleneck, large number of pending requests in ASP.NET 3.5 + 2.0 application pool

Question

I am using ASP.NET 2.0, .NET 2.0 Framework and IIS 7. I can see that a large queue of "requests" appears under the "workflow" option. The recorded states look like Authenticate Request and Execute Request Handles most.

I changed aspnet.config to C:\Windows\Microsoft.NET\Framework64\v2.0.50727 (32-bit path and 64-bit path) to include:

 maxConcurrentRequestsPerCPU="50000" maxConcurrentThreadsPerCPU="0" requestQueueLimit="50000" 

I changed machine.config to 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" 

However, I get this problem.

The problem manifests itself as a large number of requests in the Worker Process queue.

The number of current connections to the website displays 500 when this problem occurs. I don’t think I saw more than 500 parallel connections without this problem.

The web application slows down as a block of requests.

Updating the application pool is allowed for some time (as expected), since the load is distributed between the two pools.

An update pool of 50,000 was installed in the application pool specified in FIXED REQUEST.

Note. I believe the .NET 3.5 platform uses the 2.0 appnet framework and machine configuration files.

Server resources (CPU, RAM) are not used in full.

Answer 1

Ended up workflow from 1 to 2 (web garden). The problem has not recurred since, although they used the sessions, but for a month there were no reports of session problems with end users.

EDIT ADD:

The specific problem is related to the generation of extremely large CSV reports that are processed on the workflow side of the workflow, and not the error, just how it works. HTML reports are fine; XML conversion is passed on the client side.

Separation of workflows resolved the problems until the conversion of the xml aside to the creation of the csv file could be transferred to the add process, which eliminates any influence of other users. It was just up to the file size / number of lines that we worked with when trying to create CSV reports.

Answer 2

May I suggest you familiarize yourself with the materials of the Tess Ferrandez website. If it is broken, correct it.

What you want to do is capture a workflow dump using ADPlus at a time when you experience a large number of requests in the request queue and when the application starts to stop.

Once you have captured this dump, you want to load it into WinDBG + SOS and start tracking the culprit.

Tess has an excellent series of laboratory works on how to use these tools more effectively:

.NET Debugging Demos - setup and configuration instructions

If you are able, then you can also attach the profiler to the application (for example, RedGate Performance Profiler , to try to find the root cause.

Answer 3

Follow the KB article http://support.microsoft.com/kb/821268 and update me if you are still encountering this problem.

You can also try the FREB trace in IIS 7. http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/