In this article of our ASP.NET performance series, we’ll discuss Deployment Considerations. Physical deployment plays an important role in determining the performance and scalability characteristics of your application. Unless you have a compelling reason to introduce a remote middle tier, you should deploy your Web application’s presentation, business, and data access layers on the Web server. The only remote hop should be the hop to the database.
The sections below discuss key deployment considerations:
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.
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.
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.
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.
Before you deploy your application, configure the memory limit. Configuring the memory limit ensures optimal ASP.NET cache performance and server stability.
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” />
You might 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.
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 includes settings for waitChangeNotification and maxWaitChangeNotification. 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.
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 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.
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.
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.