16.2. Preparing for Web Farm Deployment

In many situations, there is no need to deploy an application across multiple servers. The anticipated load is not sufficient to warrant the extra investment. However, if the load increases and performance tuning can't yield enough improvement, you may find that it is necessary to scale your Web application beyond a single server. A Web farm is a cluster of servers that work together to service requests for a single application. The ASP.NET platform scales well from a single server into a full Web farm environment, but you do need to take a few extra steps in preparation and deployment.

16.2.1. Setting the MachineKey

The primary concerns related to deploying an application to a cluster of servers are not unique to AJAX. The ViewState data transmitted with a page is hashed by a hashing routine that is tied to the MachineKey of that server. The hash validation on subsequent requests can detect if anyone has modified the data. Problems arise when one server handles a request, but the subsequent request goes to a different server in the Web farm. If the MachineKey values are unique, as they would be by default, then you can't successfully balance the requests of an individual user across multiple machines.

To setup a Web farm for ASP.NET, you must synchronize the MachineKey values for all servers that are part of the Web farm cluster. If the MachineKey values are not identical, ViewState created by one server will be treated as invalid when it is posted to another server. This isn't because of any action by the user. The Web farm will simply be balancing requests across multiple machines. You take a random alphanumeric string and put it in the .config section for MachineKey in place of the default value of AutoGenerate, which would provide a key for you but not persist it in the configuration data. When the MachineKey values are coordinated, the ViewState hashed by one server will be validated by another that has the same key.

16.2.2. Handling Session State

Session state storage is another concern in Web farm environments. The default for session state is to store the data in-memory. 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 require setup and maintenance of a back-end 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 servers in the cluster, and then all the Web servers must point to it as the repository of all session state data. The configuration data you use is a value to indicate 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 back-end database. Although leveraging a database as a state server is slower than using the Windows Service running on the same box, it can eliminate a single-point-of-failure risk 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 and after, the provider architecture allows for any back-end data service to be plugged in for storing and retrieving session data.

<configuration>
 <system.web>
  <sessionState mode="Custom" customProvider="SampleProvider">
   <providers>
    <add name="SampleProvider" type="SampleProvider" />
   </providers>
  </sessionState>
 </system.web>
</configuration>

In addition to making the state server pluggable, Microsoft has released the sources for the 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 released providers is not a good match. Additionally, some members of the community have offered up custom provider implementations for other data storage solutions. You can learn more at www.asp.net.