Article ID: 815162 - View products that this article applies to.
This step-by-step article discusses how to set up multi-server ASP.NET Web Applications and Web services. For most uses of ASP.NET, a single server can handle all requests in a timely manner. However, many environments must deploy multiple servers to handle consistently high volumes of traffic, to support processor-intensive applications, to respond to sudden bursts in traffic, or to meet redundancy requirements.
In the simplest form, you can deploy Web pages that consist only of static HTML pages and images in a multi-server configuration by copying the files to multiple Web servers and then configuring a load balancing mechanism to distribute requests between the Web servers.
As the Web site complexity increases, the difficulty of synchronizing files and configurations between the servers also increases. Dynamic sites require multiple servers to have access to a single database and to share state information among themselves. This article describes how to design multi-server ASP.NET solutions that include databases and sessions.
By default, ASP.NET stores session information in the server memory. This configuration is known as in process. Although this configuration provides the best performance possible, you lose the session information if you restart the ASP.NET server. Additionally, in multi-server architectures, a single user’s request can be sent to a different server. A user may start a session at one server, but later requests are sent to a different in-process server. This results in a new session being created for that user and all earlier information that was stored in the session is lost.
ASP.NET provides two solutions for sharing state information between multiple servers: the ASP.NET State Server service, and Microsoft SQL Server. You can use either of these solutions to store state information between server restarts, and to allow users to move between servers during a single session. For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/317604/EN-US/ )HOW TO: Configure SQL Server to Store ASP.NET Session State
(http://support.microsoft.com/kb/815159/EN-US/ )HOW TO: Analyze ASP.NET Web Application Performance by Using the Performance Administration Tool
You can copy configuration files to servers by using any standard file copy or synchronization method, including DFS, the File Replication service, and Microsoft Application Center 2000. The following batch file will work in environments where each Web server has the virtual server root folder shared as wwwroot$:
When you deploy configuration information and ASP.NET content to multiple servers, it is critical to deploy the content from a single staging server to all production servers at the same time. This reduces the chance of problems occurring when a user’s requests are sent to different servers. Microsoft recommends that all configuration and content updates occur on the staging server. Ideally, this staging server does not receive requests from users. It is dedicated to the task of testing and deploying new content.
When you replicate updated .config files to a Web server, that Web application automatically restarts.
Note If you put assemblies in the Global Assembly Cache, you cannot replicate them by using file synchronization.
For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/315736/EN-US/ )HOW TO: Secure an ASP.NET Application by Using Windows Security
(http://support.microsoft.com/kb/315588/EN-US/ )HOW TO: Secure an ASP.NET Application Using Client-Side Certificates
(http://support.microsoft.com/kb/818015/EN-US/ )HOW TO: Tune and Scale Performance of Applications That Are Built on the .NET Framework