In many situations, there is no need to deploy an application on multiple servers. The anticipated load is not enough to warrant the extra investment. However, if the load increases and performance tuning can’t gain enough performance, you may find that it’s necessary to scale your web application beyond a single server. A web farm is a cluster of servers all working together to service requests for a single application. The ASP.NET platform scales well from a single server into a web farm environment, but you do need to take a few extra steps to get things set up.
The primary concerns related to deploying an application to a cluster of servers are not really AJAX-spe-cific. Problems arise when a server handles a request from a browser where the previous request was serviced by a different server. The ViewState data in the page is hashed by a hashing routine tied to the MachineKey, and the hash prevents anyone from modifying the data. To synchronize all the web servers in a web farm, you need to ensure that the MachineKey is the same across all of the applications on all servers. If the MachineKey values are not identical, ViewState sent by one server will be treated as invalid when posted to another server. You can simply take the MachineKey from one machine and copy it across all servers in the web farm, or you can generate your own set of random characters to use at the application scope.
Session state storage is another concern in web farm environments. The default for session state is to store the data in-memory, so requests that get handled by another server will not have access to the correct session data. To ensure the fastest performance, ASP.NET prefers to use in-memory session state to avoid the need to go to another process or to a database.
To support web farms, however, ASP.NET also provides an out-of-process session state server that can be referenced by multiple servers. This is a Windows service that must run on one of the web servers, and then all the web servers must point to that one as the repository of all session state data. The configuration data indicates that the mode is StateServer instead of InProc. The server running the state service and the port and protocol are also specified.
<configuration> <system.web> <sessionState mode="StateServer" stateConnectionString="tcpip=dataserver:42424" cookieless="false" timeout="20"/> </sessionState> </system.web> </configuration>
The State Server allows you to start sharing sessions across multiple machines but doesn’t scale as well as a backend database. Although leveraging a database as a State Server is slower than the Windows Service, it can eliminate the single-point of failure if you have a robust clustered database. In ASP.NET 1.0, a SQL Server could be configured as the storage point for session information. In ASP.NET 2.0, the provider architecture allows any backend to be plugged in for storing and retrieving session data.
In addition to making the State Server pluggable, Microsoft has released the sources for its SQL session state provider. This is a great resource for developing your own session state provider if you have an environment where one of the shipping providers is not a good match.
<configuration> <system.web> <sessionState mode="Custom" customProvider="SampleProvider"> <providers> <add name="SampleProvider" type="SampleProvider" /> </providers> </sessionState> </system.web> </configuration>