ASP.NET 2.0 Performance Guidelines - Deployment Considerations

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Srinath Vasireddy, Ashish Babbar, John Allen, and Alex Mackman


Avoid Unnecessary Process Hops

Although process hops are not as expensive as machine hops, you should avoid process hops where possible. Process hops cause added overhead because they require interprocess communication (IPC) and marshaling. For example, if your solution uses Enterprise Services, use library applications where possible, unless you need to put your Enterprise Services application on a remote middle tier.


Understand the Performance Implications of a Remote Middle Tier

If possible, avoid the overhead of interprocess and intercomputer communication. Unless your business requirements dictate the use of a remote middle tier, keep your presentation, business, and data access logic on the Web server. Deploy your business and data access assemblies to the Bin directory of your application. However, you might require a remote middle tier for any of the following reasons:

  • You want to share your business logic between your Internet-facing Web applications and other internal enterprise applications.
  • Your scale-out and fault tolerance requirements dictate the use of a middle tier cluster or of load-balanced servers.
  • Your corporate security policy mandates that you cannot put business logic on your Web servers.

If you do have to deploy by using a remote middle tier, ensure you recognize this early so that you can measure and test by using the same environment.


Short Circuit the HTTP Pipeline

The HTTP pipeline sequence is determined by settings in the Machine.config file. Put the modules that you do not use inside comments. For example, if you do not use Forms authentication, you should either put the entry for Forms authentication in the Machine.config file in a comment or, explicitly remove the entry in your Web.config file for a particular application. The following sample shows how to comment out an entry.


The following sample from a Web.config file shows how to remove the entry for a specific application.

   <remove name="FormsAuthentication" />

If you have other applications on your Web server that are using the HTTP module that you do not use, remove the HTTP module from the Web.config file of the application. Do this instead of using comments to disable the HTTP module in the Machine.config file.


Configure the Memory Limit

When using ASP.NET process model, configure and tune the memory limit using memoryLimit attribute in the <processModel> element of Machine.config file. When using of IIS 6.0 process isolation model configure and tune the memory limit using Memory recycling application pool setting.


ASP.NET trims memory in the cache based on a LRU algorithm and the CacheItemPriority value. If the memory limit is set too high, it is possible for the process to be recycled unexpectedly or your application may experience out-of-memory exceptions. If the memory limit is set too low, it could increase the amount of time spent performing garbage collections, which decreases overall performance.


If the process is being recycled unexpectedly or if your application is giving out-of-memory exceptions, you should consider memory tuning. The default setting is optimized to minimize paging. If you observe high paging activity (by monitoring the Memory\Pages/sec performance counter) you can increase the default limit, provided that your system has sufficient physical memory.


Measure the total memory consumed by the ASP.NET worker process by measuring the Process\Private Bytes (aspnet_wp) performance counter along with paging activity in System Monitor. If the counter indicates that the memory consumption is nearing the default limit set for the process, it might indicate inefficient cleanup in your application. If you have ensured that the memory is efficiently cleaned. Then you will need to increase the memory limit.

ASP.NET Process Model When using the ASP.NET process model, you configure the memory limit in the Machine.config file as follows.

< processModel memoryLimit="60" .../> 

This limit is important to adjust when your server has 4 GB or more of RAM. The 60 percent default memory limit means that the worker process is allocated 2.4 GB of RAM, which is larger than the default virtual address space for a process (2 GB). This disparity increases the likelihood of causing an OutOfMemoryException. To avoid this situation in .NET Framework 1.0, you should set the limit to the smaller of 800 MB or 60 percent of physical RAM. .NET Framework 1.1 supports a virtual space of 3 GB. If you put a /3GB switch in boot.ini, you can safely use 1,800 MB as an upper bound for the memory limit.

IIS 6.0 Process Isolation Model When using the IIS 6.0 process isolation model, you can configure the memory limit as follows.

  • Open the Internet Information Services (IIS) Manager.
  • Right click the Application pool.
  • On the properties, select the Recycling tab.
  • Unselect the Recycle worker process (in minutes):.
  • In the Memory recycling section select Maximum used memory (in megabytes)
  • Set the memory limit to the calculated limit

Note The Memory recycling application pool setting allows you to specify separate limits for physical memory and virtual memory. Physical memory (or a combination of both physical and virtual memory) is commonly used for ASP.NET applications because of the way the common language runtime's garbage collector works. Virtual memory is commonly used for classic native applications that fragment the heap.

Problem Example

An ASP.NET application is deployed on web server having 2 GB RAM. It is configured to use ASP.NET process model. The default memory limit is set to 60% using the memoryLimit attribute of <processModel> element in Machine.config file as follows.

<processModel memoryLimit="60" .../>

Unfortunately the process recycles after the total memory consumed by the process exceeds 60 percent of the physical RAM, in this scenario 1.2 GB. This will cause the process to recycle even in normal load conditions.

Solution Example

An ASP.NET application is deployed on web server having 2 GB RAM. It is configured to use ASP.NET process model. The normal memory consumption of the application process is determined and memoryLimit is configured accordingly.

Monitor the worker process memory by using Process\Private Bytes (aspnet_wp) performance counter. The counter reveals that the process requires 1.3 GB of memory in the normal load conditions.

Since the web server has 2 GB of RAM and the default memoryLimit is 60%, the application process will get recycled when the memory consumption reaches 1.2 GB, in other words the process will be recycled in normal load condition. Set the memoryLimit attribute of the <processModel> element in Machine.config file as follows.

<processModel memoryLimit="70" .../>

With this settings the process will recycles after the total memory consumption exceeds 70 percent of the physical RAM i.e. 1.4 GB. Thus the process will not get recycled in normal load conditions.


Disable Tracing and Debugging

Before you deploy your application, disable tracing and debugging. Tracing and debugging may cause performance issues. Tracing and debugging are not recommended while your application is running in production.

Disable tracing and debugging in the Machine.config and Web.config files, as shown in the following sample.

   <trace enabled="false" pageOutput="false" />
     <compilation debug="false" />

Note You may also want to verify that tracing and debugging are not enabled on individual pages. Individual page settings override the settings in the Web.config file.


Ensure Content Updates Do Not Cause Additional Assemblies to Be Loaded

Problems may arise when updates to .aspx or .ascx pages occur without an application restart. Consider the following scenario. Assume you have five pages in a directory as follows.


When a page in the Mydir directory is first requested, all pages in that directory are compiled into a single assembly, as shown in the following sample.

Assembly1.dll {page1.aspx, page2.aspx, page3.aspx, page4.aspx}

If Page1.aspx is updated, a new single assembly is created for Page1.aspx. Now there are two assemblies, as shown in the following sample.

Assembly1.dll {page1.aspx, page2.aspx, page3.aspx, page4.aspx, page5.aspx}
Assembly2.dll {page1.aspx}

If Page2.aspx is updated, a new single assembly is created for Page2.aspx. Now there are three assemblies.

Assembly1.dll {page1.aspx, page2.aspx, page3.aspx, page4.aspx, page5.aspx}
Assembly2.dll {page1.aspx}
Assembly3.dll {page2.aspx}

To ensure that you do not experience this problem and generate multiple assemblies, follow these steps when you want to update content:

1. Remove the Web server from rotation. 1. Restart IIS. 1. Delete all files in the Temporary ASP.NET Files folder. 1. Request a single page in each directory to ensure that each directory is batch compiled. 1. Put the Web server back into rotation.

This approach to updating content also solves another problem. If a server is put into rotation before batch compilation is complete, some pages may be compiled as a single assembly. If another request is made during batch compilation for a page in the same directory that is being batch compiled, that page is compiled as a single assembly. Taking the Web server out of rotation and then putting it back in rotation helps you avoid this problem.


Avoid XCOPY Under Heavy Load

XCOPY deployment is designed to make deployment easy because you do not have to stop your application or IIS. However, for production environments you should remove a server from rotation, stop IIS, perform the XCOPY update, restart IIS, and then put the server back into rotation.

It is particularly important to follow this sequence under heavy load conditions. For example, if you copy 50 files to a virtual directory, and each file copy takes 100 milliseconds, the entire file copy takes 5 seconds. During that time, the application domain of your application may be unloaded and loaded more than once. Also, certain files may be locked by the XCOPY process (Xcopy.exe). If the XCOPY process locks certain files, the worker process and the compilers cannot access the files.

If you do want to use XCOPY deployment for updates, the .NET Framework version 1.1 includes the waitChangeNotification and maxWaitChangeNotification settings. You can use these settings to help resolve the XCOPY issues described in this section.

Note These settings are also available in a hotfix for .NET Framework version 1.0. For more information, see Knowledge Base article 810281, "Error Message: Cannot Access File AssemblyName Because It Is Being Used by Another Process," at;en-us;810281.

The value of the waitChangeNotification setting should be based on the amount of time that it takes to use XCOPY to copy your largest file. The maxWaitChangeNotification setting should be based on the total amount of time that XCOPY uses to copy all the files plus a small amount of extra time.


For more information, see the following Knowledge Base articles:

Consider Precompiling Pages

So that your users do not have to experience the batch compile of your ASP.NET files, you can initiate batch compiles by issuing one request to a page per directory and then waiting until the processor idles again before putting the Web server back into rotation. This increases the performance that your users experience, and it decreases the burden of batch compiling directories while handling requests at the same time.


Consider Web Garden Configuration

Consider using Web gardens if your application uses STA objects heavily or if your application accesses a pool of resources that are bound by the number of processes.

To determine the effectiveness of Web gardens for your application, run performance tests, and then compare the results with and without Web gardens.


Consider Using HTTP Compression

HTTP compression is supported by most modern browsers and by IIS. HTTP compression is likely to improve performance when the client accesses the Web server over a low bandwidth connection.


Consider Using Perimeter Caching

A perimeter network protects your intranet from intrusion by controlling access from the Internet or from other large networks. It consists of a combination of systems such as proxy servers, packet filtering, gateways, and other systems that enforce a boundary between two or more networks.

If your perimeter network includes a proxy server, consider enabling caching on your proxy server to improve performance.


Personal tools