Best practices for 'InProc' vs 'StateServer' for ASP .NET session state

Question

We have a single ASP .NET application running on a single web server (no farm). For now, we're using the default 'InProc' session storage. Is it worth considering using the ASP .NET state service instead? If we went that route we'd likely just run the service itself on the same machine as the application, so making calls out over the network to get and set session info wouldn't be an issue. The reason we are considering this at all is to help avoid session data being lost when the app pool recycles.

Also, using SQL Server is off the table for now, so we're just talking about in-process vs state server.

What are the pros and cons to each mode in this scenario?

Answer 1

I like to use the StateService simply because it is one less thing to change if you do ever need to distribute your App across multiple servives. And it allows you to recycle IIS without losing all sessions. Though this is not that useful with only one server it just seems like soemthing nice to have.

My reasons are more a general feeling than anything else. But Ive never had a problem with it.

Answer 2

I think that this is a classic case of YAGNI.

InProc is easy and effective. Barring a specific need for a separate state service, why would you consider making such a change? Indeed, given that the only real advantage comes if you are distributing your site over multiple servers - and you aren't distributing your site over multiple servers, this may well turn out to be wasted effort. Even if you are pretty sure that you'll eventually migrate to multiple servers, I wouldn't make the switch unless and until it comes time to boot up that second server. Again, read the article at the YAGNI link to understand why.

Instead, use the time you'll save to improve your site...

More information on your alternatives can be found here...

Answer 3

Well the state server is a little slower than in proc. The benefit you will get out of it is that if you need to recycle the app pool, then the state of the application (user sessions etc.) will be unaffected. If you plan on using a state server in the future, I would start using it now. With in process, objects are stored in memory as is, but with the state server they are serialized. This can be a big deal if you plan on making the switch later as you'll have to check that everything you store in state is serializable. If you start out with that restraint, you know up front (while you're actively working on that module) what is going to work and what isn't.

Answer 4

I'm pretty sold on always using StateService, no matter what. We used to just use InProc, but it turns out there are (apparently) all kinds of strange ways the appPool can get recycled without you knowing about it.

We used to have clients loose their sessions while in the web system once a week or so, due to some kind of inexplicable recycling action. Once we switched to StateService, we haven't had that problem once.

Answer 5

Correct me if I am wrong but from what I read out there, there is another pros/cons:

inproc forces to use a single workerprocess, thus losing sessionstate upon recycling

stateserver allows using a web garden (i.e. configure the application pool to run over e.g. 4 workers)