Design and Configuration for Performance

Article
12/04/2014

This topic discusses design, configuration, compilation, and memory options available to improve the performance of a Web application.

Asynchronous Programming Models

ASP.NET supports asynchronous programming techniques that allow you to move a long-running task such as a database query to a thread that runs separately from the main application thread. You can use the following techniques:

BackgroundWorker component The BackgroundWorker class in the System.ComponentModel namespace enables you to add the code for the time-consuming task to the DoWork event handler and call the RunWorkerAsync method to raise the DoWork event. The calling thread continues to run while the worker method runs asynchronously. When the method is finished, the BackgroundWorker component alerts the calling thread by raising the RunWorkerCompleted event. For more information, see BackgroundWorker Component.
Event-based asynchronous programming The event-based asynchronous pattern can take several forms, depending on the complexity of the operations supported by a particular class. The simplest classes may have a single MethodNameAsync method and a corresponding MethodNameCompleted event. More complex classes may have several MethodNameAsync methods, each with a corresponding MethodNameCompleted event, as well as synchronous versions of these methods. Classes can optionally support cancellation, progress reporting, and incremental results for each asynchronous method.

An asynchronous method may also support multiple pending calls (multiple concurrent invocations), allowing your code to call it any number of times before it completes other pending operations. Correctly handling this situation may require your application to track the completion of each operation.

For a complete description of this pattern and its implementation, see Event-based Asynchronous Pattern Overview.
Asynchronous programming using IAsyncResult An asynchronous operation that uses the IAsyncResult design pattern is implemented as two methods named BeginOperationName and EndOperationName that begin and end the asynchronous OperationName respectively. BeginOperationName returns control to the calling thread immediately. The EndOperationName method ends asynchronous OperationName. The timing of the call to EndOperationName is important, because it blocks the calling thread if OperationName has not completed. For more details, see Asynchronous Programming Model (APM).
Clients callbacks In a client callback, a client script function sends a request to an ASP.NET Web page without the overhead of a postback.

For an example that uses some of these techniques, see Event-based Asynchronous Pattern Technology Sample.

Compilation and Configuration Options

The way in which you compile and configure your application affects how well it performs. The following guidelines suggest ways to make your Web applications as a whole work efficiently:

If you have a large Web application, precompile it. (You have to compile a Web application project, but precompiling is optional for a Web site project. For more information, see Web Application Projects versus Web Site Projects in Visual Studio.)
Recycle processes when running ASP.NET Web applications on Internet Information Services 5.0.
If necessary, adjust the number of threads per worker process for your application. For applications that rely extensively on external resources, consider enabling Web gardening on multiprocessor computers.
Disable debug mode.
Tune the configuration files for your Web server computer and for specific applications to suit your needs using the following techniques:
- Enable authentication only for applications that need it.
- Configure your application to use the appropriate request and response encoding settings.
- Consider disabling AutoEventWireup for your application.
- Remove unused modules from the request-processing pipeline.

For more details, see ASP.NET Performance Overview.

Cache Configuration Options

To improve application performance, you can configure caching at the following levels:

Application In an application's Web.config file, you can use the OutputCacheSection element to control caching for the entire application. Using the OutputCacheSettingsSection element, you can set up cache profiles which can then be applied to individual pages.
Machine You can configure the same options in the Machine.config file that you can in the Web.config file.
Page You can configure caching in individual pages by applying cache profiles that have been defined in a configuration file. Alternatively, you can configure individual cache properties in the @ OutputCache directive or by setting attributes in the page's class definition.
Control You can configure user-control caching by setting the @ OutputCache directive in the user-control file or by setting the PartialCachingAttribute attribute in the control's class definition.

For more information, see Cache Configuration in ASP.NET.

Memory Recycling with IIS 6.0

If an application contains code that causes problems, such as a COM interop application with known memory leaks, and you cannot easily rewrite the code, it might be useful to limit the extent of the problems by periodically recycling the worker process that services the application. Worker process recycling replaces an instance of the application in memory. IIS 6.0 can automatically recycle worker processes by restarting the worker process or worker processes that are assigned to an application pool. This helps keep applications running smoothly.

Maintaining State During Recycling

If you have an application pool with applications that depend on state data, you must decide whether to recycle the worker processes that are assigned to that application pool. When you recycle a worker process, the state data for applications maintained in process is lost. In that case, you might choose not to use recycling.

You can recycle processes and solve the state problem by maintaining state data outside the worker process, such as in a database. However, maintaining state data out of process to allow recycling can affect server performance in the following ways:

Performance is reduced because of the management overhead that is needed to move the data between the application and the data store.
Recycling flushes any in-process data caches, so the caches need to be rebuilt.

ASP.NET gives you the option of persisting session state using a session state service or a SQL database. For more information, see Session-State Modes.

For more information, see Recycling Worker Processes (IIS 6.0).

Native Image Service

The Native Image Service is a Windows service that generates and maintains native images, which are files containing compiled processor-specific machine code. The native image service allows you to defer the installation and update of native images to periods when the computer is idle. The Native Image Generator (Ngen.exe) is a tool that improves the performance of managed applications. Ngen.exe creates native images and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead using the just-in-time (JIT) compiler to compile the original assembly.

For more information, see the article NGen Revs Up Your Performance with Powerful New Features on the MSDN Magazine Web site.

Global Assembly Cache and the Working Set

The working set of a process is the set of memory pages currently available to the process in physical RAM memory. These pages are resident and available for an application to use without triggering a page fault. You can monitor the size of the working set using the PeakWorkingSet and WorkingSet properties. You can reduce the working set of an application by placing assemblies in the Global Assembly Cache. This option is primarily recommended for middle-tier and shared assemblies.