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

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)).

Answer 2

In an n-tier environment, with SQL Server hosting session state you'll create additional network traffic to your back-end, as well as losing some SQL Server resources that will need to now take care of that additional traffic (session-related requests). SQL Server state management is also slower than state server.

However, if your servers go down in some unforeseen incident, SQL Server will most likely maintain the session information, as opposed to a state server.

Answer 3

In my personal experience I had a few problems storing in session variables. I kept loosing the session and I believe it was the anti virus, which, as it was scanning every file in the server, IIS would recompile the site killing the sessions. (I must say I had no power over that server, I was told to host the app there)
So I decided to store the session in the SQL Server and everybody is happy now... it is incredibly fast

Take a look at this article for a quick start up

Answer 4

Using a single machine to store state in a web garden means a single point of failure. We use SQL state, but it does add a bit of overhead.

Answer 5

In Proc is very Fast. But having limitation. we can use single system only. When the time of reboot the System, information will be lost. worker processes in same machine

StateServer stored the session information in other machine. Web Farm can use the session. for ex: multiple worker-processes can access the session information from server. When the time of rebooting server, information will be lost.

SQLServer is used to store the info in Table. Default it will store in TempDB. This tempdb will dynamically call after sqlservice is called. So this also not persist the data. In this Scenario we can store in our own DB using Script, that is called Custom Option.

Answer 6

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).