• Choose a category
• All
• Classic-Fiction

memoryLimit

Indicates the percentage of memory that the worker process can consume before being recycled by IIS. The number indicates the percentage of the total system memory. The default value is 60.

minIoThreads

Configures the minimum number of I/O threads to use for the process on a per-CPU basis. The default is 1.

minWorkerThreads

Configures the minimum amount of worker threads to use for the process on a per-CPU basis. The default is 1.

requestQueueLimit

Indicates the number of requests the ASP.NET process can queue before returning error 503 ( Server too busy.) The default is 5000.

responseDeadlockInterval

Indicates the time after which a process with queued requests that has not returned a response is considered deadlocked and is shut down. The default is three minutes.

Let’s consider some alternatives, starting with memory limits. The default value of 60 has been determined by looking at an average scenario where your application is likely not to be the only one on the server. However, if you’re lucky enough to be the only server process that consumes memory, the number can set to a higher threshold such as 75 without raising significant issues.

I/O threads are threads used to perform asynchronous operations that tend to take a while to complete. The typical example is reading a file or calling into a Web service. I/O threads are implicitly set up by high-level code you call usually through BeginXxx methods. Worker threads are, instead, threads used for plain operations. You might want to increase the number of I/O threads or worker threads based on the characteristics of your application. As you might have noticed, two minimum settings exist for threads: minIoThreads and minWorkerThreads. These values determine the lower bound that, when reached, cause ASP.NET to queue successive requests. A new request for a worker process is queued when fewer than the minWorkerThreads free threads are counted. The same happens for I/O threads.

Process Model and IIS 7.x Integrated Mode

ASP.NET uses threads differently when an application is hosted in an application pool running under IIS 7 in integrated mode. The biggest difference is that by default ASP.NET counts and keeps under control the number of concurrent requests instead of the number of concurrent threads. Is this really different? The two quantities are the same except when asynchronous requests are present. Asynchronous requests, in fact, might be pending without blocking an ASP.NET thread. As a result, you can have far more requests than threads.

You can still use the settings for threads exposed by the section, but they are just ignored in integrated mode. How can you configure the maximum number of concurrent requests per CPU? A new configuration file has been added that supports an extra section named . The new configuration file is aspnet.config and is available in the .NET Framework folder. For ASP.NET 4, it is \microsoft.net\framework\v4.0.30319 under the Windows folder. You can add the following section:

maxConcurrentRequestsPerCPU="5000"

maxConcurrentThreadsPerCPU="0"

requestQueueLimit="5000" />

The requestQueueLimit value specified in aspnet.config is the same as in and will override any value you assign at the machine.config level.

Note that in integrated mode any requests are handed to ASP.NET by IIS for mere execution. When this happens, a thread switch occurs—from the IIS thread to a CLR thread. If you set maxConcurrencyRequestPerCPU to 0, the request will execute on the IIS I/O thread, without switching to a CLR thread. This is not a recommended approach because it could slow down the application when it comes to serving static resources. If you have IIS threads engaged in dynamic (and likely lengthier) requests, there are more chances that at peak times no threads are left to serve simpler requests.

In integrated mode, ASP.NET defaults to counting requests instead of threads. You can change