What is the best solution for storing ASP.NET session variables? StateServer or SQLServer?

Question

StateServer or SQLServer?

• What is the best solution for storing ASP.NET session variables?
• What are the pros and cons of each?
• Are one better then other in any particular situation?

Answer 1

Here's some thoughts about pro's/con's. I've also added Microsoft Velocity Distributed Caching solution.

Pros for InProc

• Fastest optional available (it's all in memory/ram)
• Easy to setup (nothing new required in the .config file .. i think this is the default behavior).
• Most people I believe use this.

Cons for InProc

• If the web site (application pool) dies, then all session info is lost.
• Doesn't work in a WebFarm scenario -> session information is per app pool only.
• Cannot contain non-session information.

Pro's for a StateServer

• In memory/ram, so it's fast (but has some net latency .. read below), so it might not be as fast as Inproc.
• Default configuration for a web farm scenario. Multiple iis sites use a stateserver to control the state session info.

Con's for StateServer

• Requires the ASP.NET StateServer service to be set to run.
• StateServer requires some config tweaking to accept 'remote iis machine' requests.
• There's some tiny tiny net latency if the iis request needs to grab/set the session info on another networked machine.
• Cannot contain non-session information.

Pro's for SqlServer (as a state server)

• State is always retained, even after the iis site restarts.

Con's for SqlServer (as a state server)

• Slowest solution -> net latency AND hard-drive latency (as the sql server stores the state on the harddisk / reads from the harddisk).
• Hardest to setup/configure.
• Cannot contain non-session information

Pro's for Velocity (or other distributed caching systems)

• Can handle more than just session information -> objects, application settings, cache, etc. (This is a very GOOD thing IMO!!)
• Can be memory only or persist to a database.
• If one 'node' fails, the system still works. (assuming there's 2+ caching nodes)

Con's for Velocity (or other distributed caching systems)

• Generally cost $$$
• Hardest to setup (have to install stuff, tweak configs, add extra specal code).
• Has network latency (which is generally nothing) but could have hard disk latency IF the service is persisting the data (eg. to a Sql Server).

Answer 2

I think the assumption would be that you are using a web farm of some sort.

One use of state service is in a Web Garden (multiple worker-processes on the same machine). In this case, you can use load-balancing to keep a user's connection going to a particular server, and have the n worker processes all sharing the same state service.

EDIT: In the web garden + state service or sql server scenario, you also have the benefit of being able to recycle the worker processes on that machine w/o the connected clients losing their session.

I'm not as familiar with using SQL Server as a session state store, but I would think you would gain robustness by using an SQL Server in a cluster. In this case, you could still have multiple worker processes and multiple servers, but you would not have to use a sticky session (server affinity).

And one more note, you can use state service on a second machine, and have all server in the farm hit that machine, but you would then have a single point of failure.

And finally, there are 3rd party (and some home-grown) distributed state-service-like applications. Some of these have performance benefits over the other options, plus Session_End event will actually fire. (In both State Service and SQL Server session backing, there the Session_End in Global.asax will not fire (there may be a way of hooking into SQL Server)).