iis7 large worker process request queue creating process blocking aspnet.config & machine.config amended (bottleneck)

Question

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:

  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="true"
maxIoThreads="100"              
maxWorkerThreads="100"
minIoThreads="50"
minWorkerThreads="50"

    minFreeThreads="176" 
    minLocalRequestFreeThreads="152" 

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

C:\Windows\Microsoft.NET\Framework64\v3.5

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 ?

Answer 1

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;".

Example:

<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

Example:

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

---

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

---

processModel

Example:

<processModel 
   enable="true"
   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 -->
/>

---

connectionManagement

Example:

<system.net>
  <connectionManagement>
    <add address="*" maxconnection="100" <!-- Default is 2 --> />
  </connectionManagement>
</system.net>

Answer 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.