ASP.net 2.0 app .net 2.0 framework IIS7

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:


I have amended machine.config in C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG (32 bit and 64 bit path) to include:



Still i get the issue.

The issue manifestes itself as a large number of processes in the Worker Process queue.

Number of current connections to the website display 500 when this issue occurs. I dont think i have seen concurrent connections over 500 without this issue occurring.

Web application slows as the request block.

Refreshing the app pool resolves for a while (as expected) as the load is spread between the two pools.

Application pool in question FIXED REQUEST have been set to refresh on 50000.

Thank you for any help. Scott

quick edit to say hmm, my develeopers are telling me the project was built with .net 3.5 framework. Looking at


there does not appear to be a ASPNET.CONFIG or a MACHINE.CONFIG .... is there a 3.5 equivalent ?

after a little searching apparenetly 3.5 uses the 2.0 framework files that 3.5 is missing.

So back to the original question , where is my bottleneck ?

  • You have autoConfig = true. Can you have that enabled and customize the threads?
    – tresstylez
    Oct 31, 2014 at 19:00
  • I am experiencing same in .net 4.5 application hosted on windows 2012 r2 Nov 16, 2015 at 9:40

2 Answers 2


IIS Optimization and Performance Tuning is quite a broad topic, and your bottleneck(s) could be several places.

First, you can better determine what your bottlenecks are by using the Performance Monitor.

Based on what you find there, you can move on to trying the following IIS performance tuning options:

  1. Use IIS Compression.
  2. Enable at least static caching, and enable dynamic caching if it makes sense to do so.
  3. Tune your Aspnet.config files and machine.config files and web.config connection strings for your application(s).

Checking your connection strings in web.config

By default, the max pool size for connection strings in a web.config file is 100, so try specifying something higher, like "Max Pool Size=200; Min Pool Size=10; Connect Timeout=45;".


<add name="SiteSqlServer" connectionString="Server=mydomain.com;Initial Catalog=myDB;User ID=DB;Password=myDB;Max Pool Size=100;Min Pool Size=10;Connect Timeout=45;" providerName="System.Data.SqlClient" />

Checking your settings in Aspnet.config

Location: C:\Windows\Microsoft.NET\Framework\v2.0.50727 and C:\Windows\Microsoft.NET\Framework64\v2.0.50727


    <applicationPool maxConcurrentRequestsPerCPU="5000" <!-- Default is 12 -->
             maxConcurrentThreadsPerCPU="0" <!-- Default is 0 -->
             requestQueueLimit="5000" <!-- Default is 5000 -->/>

Checking your settings in machine.config

Location: C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG and C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG



   requestQueueLimit="5000" <!-- Adjust if necessary. Default 5000 -->
   restartQueueLimit="10"  <!-- Adjust if necessary. Default 10 -->
   memoryLimit="60" <!-- Adjust if necessary. Lower for memory leaks. -->
   maxWorkerThreads="100" <!-- Default 20 -->
   maxIoThreads="100" <!-- Default 20 -->
   minWorkerThreads="40" <!-- Default 1 -->
   minIoThreads="30" <!-- Default 1 -->



    <add address="*" maxconnection="100" <!-- Default is 2 --> />

You may be able to make slight headway with server changes, but in this case it sounds like the real issue is with the code. Something is preventing the code from completing in a timeline manner, causing the requests to build.

Use your worker process queue to tell which page is building the longest. It may be a single page, or a pattern of pages, or if it's not, then usually there is one page at the top that is holding everything else up.

Debug Diag is a great tool for more advanced troubleshooting to isolate the locking page.

You're right about the framework versions. .NET 3.0 and 3.5 are extensions to 2.0. It's not until 4.0 that there is a whole new framework version with corresponding aspnet_isapi.dll and other core files.

  • Thank you for the reply. Seems to be a mass of worker processes accumulating. I have a NAGIOS watch on the index page checking it can load , sometimes it detects the index page is slow , sometimes the index page is fine and the rest of the app is slow after login. In both cases the number of worker processes are off the chart with very high elapse times. Any tips on how to configure DEBUG DIAG and then interpret the data ? Thank you for the response. Apr 20, 2011 at 6:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .