The following guidelines suggest ways on how to make your Web applications as a whole work efficiently.

Web application is batch-compiled on the first request for an application resource such as a page. If no page in the application has been parsed and compiled, the batch compilation feature will parse and compile all pages in the directory in chunks to provide better disk and memory usage. This feature gives ASP.NET a performance benefit, since it compiles many pages into a single assembly. Accessing a page from an assembly that is already loaded is faster than loading a new assembly per page. Note that if batch compilation of multiple pages into a single directory exceeds the number of seconds specified for the BatchTimeout property, a single page will be parsed and compiled so that the request can be processed quickly.

The disadvantage of batch compilation is that if the server receives many requests for pages that have not been compiled, performance can be poor while the Web server parses and compiles them. To solve this problem, you can precompile the application.

By default, ASP.NET on IIS 5.0 will service requests using an out-of-process worker process. This feature has been tuned for fast throughput. Because of its features and advantages, running ASP.NET in an out-of-process worker process is recommended for production sites.

You should recycle processes periodically, for both stability and performance. Over long periods of time, resources with memory leaks and bugs can affect Web server throughput, and recycling processes cleans up memory from these types of problems. However, you should balance the need to periodically recycle with recycling too often, because the cost of stopping the worker process, reloading pages, and re-obtaining resources and data can override the benefits of recycling.

ASP.NET Web applications running on Windows Server 2003, which uses IIS 6.0, do not need to have the process model setting adjusted because ASP.NET will use the IIS 6.0 process model settings.

The request architecture of ASP.NET tries to achieve a balance between the number of threads executing requests and available resources. The architecture allows only as many concurrently executing requests as there is CPU power available. This technique is known as thread gating. However, there are conditions in which the thread-gating algorithm does not work well. You can monitor thread gating in the Windows Performance monitor using the Pipeline Instance Count performance counter associated with the ASP.NET Applications performance object.

When an ASP.NET Web page calls an external resource, such as when performing database access or XML Web service requests, the page request generally stops until the external resource responds, freeing the CPU to process other threads. If another request is waiting to be processed and a thread is free in the thread pool, the waiting request begins processing. The result can be a high number of concurrently executing requests and many waiting threads in the ASP.NET worker process or application pool, which hinders the Web server’s throughput, adversely affecting performance.

To mitigate this, you can manually set the limit on the number of threads in the process by changing the MaxWorkerThreads and MaxIOThreads attributes in the processModel Element (ASP.NET Settings Schema) section of the Machine.config configuration file.

NOTE: Worker threads are for processing ASP.NET requests, while IO threads are used to service data from files, databases, or XML Web services.

The values assigned to the process model attributes are the maximum number of each type of thread per CPU in the process. For a two-processor computer, the maximum number is twice the set value. For a four-processor computer, it is four times the set value. The defaults are good for one-processor or two- processor computers, but having 100 or 200 threads in the process for computers with more than two processors can be more detrimental than beneficial to performance. Too many threads in a process tend to slow down the server because of extra context switches, causing the operating system to spend CPU cycles on maintaining threads rather than processing requests. The appropriate number of threads is best determined through performance testing of your application.

The ASP.NET process model helps enable scalability on multiprocessor computers by distributing work to several processes, one per CPU, each with processor affinity set to a CPU. This technique is called web gardening, and can dramatically improve the performance of applications that rely extensively on external resources.

If your application uses a slow database server or calls COM objects that have external dependencies, to name only two possibilities, it can be beneficial to enable Web gardening for your application. However, you should test how well your application performs in a Web garden before you decide to enable it for a production Web site.

Always disable debug mode before deploying a production application or conducting any performance measurements.

If debug mode is enabled, the performance of your application can suffer significantly. For syntax information about setting the debug mode in the Web.config file, see ASP.NET Configuration Sections.

By default, ASP.NET configuration is set to enable the widest set of features and to try to accommodate the most common scenarios. Some default configuration settings can be changed to improve the performance of your applications, depending on what features you use. The following list includes configuration settings you should consider:

• Enable authentication only for applications that need it   By default, the authentication mode for ASP.NET applications is Windows, or integrated NTLM. In most cases it is best to disable authentication in the Machine.config file and enable it in the Web.config files only for applications that need it.
• Configure your application to the appropriate request and response encoding settings   The ASP.NET default encoding is UTF-8. If your application uses only ASCII characters, configure your application for ASCII for a slight performance improvement.
• Consider disabling AutoEventWireup for your application   Setting the AutoEventWireup attribute to false in the Machine.config file means that the page will not bind page events to method based on a name match (for example, Page_Load). If you disable AutoEventWireup, your pages will get a slight performance boost by leaving the event wiring to you instead of performing it automatically.

  If you want to handle page events, you will need to override the methods in the base class (for example, you will need to override the OnLoad method of the Page object for the page load event instead of using a Page_Load method).

• Remove unused modules from the request-processing pipeline   By default, all features are left active in the HttpModules node in your server computer’s Machine.config file. Depending on which features your application uses, you may be able to remove unused modules from the request pipeline to get a small performance boost. Review each module and its functionality and customize it to your needs.

  For example, if you do not use session state and output caching in your application, you can remove each from the HttpModules list so that requests do not have to invoke these modules without performing any other meaningful processing.