Challenge

Tune the machine.config file to optimize performance of an ASP.NET application. There are a number of ASP.NET settings that reside in the machine.config file provided with the .NET* Framework that can be tweaked to improve system performance. The following is an example of some of the important components of the machine.config file: httpRuntime, sessionState, and processModel:

             
            <httpRuntime
            executionTimeout=""	
            minFreeThreads=""	
            minLocalRequestFreeThreads=""
            appRequestQueueLimit= ""
            />
            <sessionState
            stateNetworkTimeout=""
            timeout=""/ >
            <processModel
            requestLimit=""
            requestQueueLimit=”"
            memoryLimit=""	
            maxWorkerThreads=""
            maxIoThreads=""
            />

Solution

Tune two parameters on the ASP.NET server: the request queue limit and the maximum number of worker threads.

The request queue limit can be found at \System\Web\httpRuntime\@appRequestQueueLimit in the machine.config file. This parameter is the maximum number of requests that will be queued before 503 “Server too busy” HTML errors are returned. When system resources such as the CPU, or available worker threads, become saturated, ASP.NET will direct the request to the ASP.NET request queue. The requests in the queue are then serviced in the order in which they arrived (FIFO) as resources become available. The request queue is very effective in handling heavy or nonsteady-state loads, but a limit must be placed on this queue, because throughput and response times will degrade as the queue grows larger.

For debugging, performance tuning, or any situation where error pages should not be returned, assigning a high value to the appRequestQueueLimit will prevent the HTTP 503 errors. To test performance in a configuration where you cannot tolerate errors being returned, set the queue size to be large enough that requests will never be rejected. In a production environment, where the server can become overloaded with requests, a balance must be made between performance and not rejecting requests.

The maximum worker thread limit can be found at \System\Web\processModel\@maxWorkerThreads in the machine.config file. This parameter is the maximum number of worker threads that will process requests.

Many Web pages rely on an external resource such as a database or Web service, and waiting on these resources will often halt the processing of that request. If more CPU bandwidth is available, it is advantageous to process another request while the other is halted. Thus, it is important to have the maximum thread count set high enough so that the CPU is saturated. Having an excessively high thread count can cause too many requests to be processed concurrently, however, which can degrade performance.

It is beneficial to run with as few threads as possible, although without sufficient worker threads, the CPU will not be fully utilized, so the optimum value must be experimentally determined.

Unfortunately, ASP.NET does not provide a performance counter to measure the number of worker threads in use. The only way to estimate this number is to use the “ASP.NET Applications\Pipeline instance count” counter. "Pipeline" in this context is an instance of your HttpApplication-derived class named Global, which resides in the Global.asax.cs file in your Web application directory. This class defines the logic of HTTP request handling inside ASP.NET, common to all types of request processing, whether HTML-based (ASPX pages) or XML-based (Web services). At any given moment, a pipeline instance can process only one request, so this counter indicates how many requests can be processed concurrently, which has some correlation to the number of worker threads.

One example of potentially needing a higher thread count is when the ASP.NET server has long-standing requests out to a database (or other external resource). It is likely that you will need to run a series of experiments to determine the optimal configuration. This procedure may need to be repeated if the design of your application changes.

Source

Developing and Optimizing Web Applications on the ASP.NET Platform