session state servers

Session in ASP.net can be stored in 3 ways.
1. Inproc
2. State Server
3. SqlServer


The InProc mode of Session State management is the fastest among all of the storage modes available and stores the Session data in the ASP.NET worker process.
Performance will be effected if the amount of data stored in the session is large. Basically the session is stored in the memory space of an application
domain and is volatile.So if asp.net worker process i.e. aspnet_wp.exe restarts then the session state will be lost.
The Session State here entirely depends on the lifetime of the application domain that it runs on. Note that the Session_End event which is fired internally by the web server is supported only in InProc mode. Note that even if the Session State is set to read only using the EnableSessionState attribute, in the InProc mode one can still modify the session. The Session_OnEnd event is invoked by the runtime environment when we make a call to the Session.Abandon() method or when the user's session times out. Further, any change made in the settings in the web.config file unloads the application domain and the Session State too.


The StateServer mode uses a stand-alone Microsoft Windows service that is independent of IIS and can run on a separate server.
In this case the session state is serialized and stored in memory in a separate process that is managed by the aspnet_state.exe file.
This has got some performance drawbacks due to the overhead involved in serialization and de-serialization of objects.
The main primary advantage of storing the Session State in a State Server is that it is not in the same process as the ASP.NET and a crash of ASP.NET
would in no way destroy the session data. Secondly, this mode of Session State storage enables to share the information across a web garden or a web farm.

Rememeber that this mode is slow compared to the InProc mode as it is stored in an external process.

The SQLServer mode of Session State management is a reliable, secure and centralized storage of a session state
In this the Session data is serialized and stored in a database table in the SQL Server database.
It can typically be used in the web farms.

It has performance bottlenecks as in the State Server mode of Session State management due to the overhead involved in serialization and de-serialization
of the objects that are stored and retrieved to and from the Session.
SQL Server is more secure than the InProc or the State server modes of Session State storages as the data can be secured easily by
configuring the SQL Server security.


Storage location

* InProc - session kept as live objects in web server (aspnet_wp.exe). Use "cookieless" configuration in web.config to "munge" the sessionId onto the URL (solves cookie/domain/path RFC problems too!)
* StateServer - session serialized and stored in memory in a separate process (aspnet_state.exe). State Server can run on another machine
* SQLServer - session serialized and stored in SQL server

Performance

* InProc - Fastest, but the more session data, the more memory is consumed on the web server, and that can affect performance.
* StateServer - When storing data of basic types (e.g. string, integer, etc), in one test environment it's 15% slower than InProc. However, the cost of serialization/deserialization can affect performance if you're storing lots
of objects. You have to do performance testing for your own scenario.
* SQLServer - When storing data of basic types (e.g. string, integer, etc), in one test environment it's 25% slower than InProc. Same warning about serialization as in StateServer.

Robustness

* InProc - Session state will be lost if the worker process (aspnet_wp.exe) recycles, or if the appdomain restarts. It's because session state is stored in the memory space of an appdomain. For details, see KB324772.
* StateServer - Solve the session state loss problem in InProc mode. Allows a webfarm to store session on a central server. Single point of failure at the State Server.
* SQLServer - Similar to StateServer. Moreover, session state data can survive a SQL server restart, and you can also take advantage of SQL server failover cluster, after you've followed instructions in KB 311029.