It seems I spend a lot of time talking to clients about .NET Session State Management and what effects their production environment might have on the user experience. Session state can be managed in several ways. I'll discuss four. Which way you choose depends on your production environment and existing infrastructure. Many session management options can be implemented in multiple configurations, I'll discuss the most common.


<p>InProc</p>
<p>In InProc session state, is when one web server caches state in application memory. Since only one web server is involved, the session state is available for the entire session’s life-cycle.This method is not practical in a ‘scale-out’ environment or web server farm with multiple web servers since that single web server’s memory is not shared among web servers. In a distributed environment, web servers require access to a central state repository.</p>
<p>Custom or Third Party</p>
<p>A custom state management solution can be built or purchased. Implementation and cost depends on the solution chosen and the complexity of the deployment.The .Net Framework includes two other options for state management.LoadBalancingArchitecture.gif</p>
<p>State Server</p>
<p>One of the web servers in a cluster can expose its state management cache for use by other web servers by running the Windows Service aspnet_state.exe. After configuration changes in the various web instances, the State Server will be sharing session cache with the other application instances.</p>
<p>It is important to note that the State Server becomes a single point of failure for the web cluster. A State Server can be used for multiple web sites in the web farm.</p>
<p>SQL Server</p>
<p>If there are SQL Servers in the production environment and the web servers have visibility to the SQL Server, state can be stored in a database created by .Net tools. State is exposed to the web servers using ADO.Net. A SQL Server can be used to manage state for multiple web sites in the web farm.</p>
<p>A SQL Server state server can take advantage of the various cluster architectures to remove a potential single point of failure.</p>
<p>Comparing Methods</p>
<p>InProc, State Server or SQL Server state management can be changed on the fly via configuration changes to the websites involved. If website state is done via the .Net HttpSessionState class, no code in the application should have to be changed to switch between state management methods.</p>
<p>More moving parts or involved infrastructure creates abstraction and reduces performance (however mildly). InProc state management is fastest as it is an ‘in memory’ model (though physical disk caching is involved), but it is not very useful for a web farm. State Server session management is an ‘in memory’ model, but involves a Windows service and network latency. It is very fast, but introduces a single point of failure in a web farm and has limited capacity bound by the amount of physical memory available. Using a SQL Server adds the overhead of disk access and multiple network protocols, but the database server can be configured in a cluster providing redundancy and might be more useful in a line-of-business application. A SQL Server also can deal with a much greater user load as it is not memory bound.</p>
<p>Depending on the system requirements with respect to application availability, response time and redundancy there is an ‘out of the box’ state management system in the .Net Framework.</p>