Geek Answers Handbook

Best Practices for InProc and StateServer for ASP.NET Session State

We have one ASP.NET application running on a single web server (without a farm). We currently use the default InProc session store. Should I consider using the ASP.NET public service? If we went along this route, we most likely would simply start the service on the same computer as the application, so making calls over the network to receive and set up session information would not be a problem. The reason we are considering this is to avoid losing session data when reusing the application pool.

In addition, the use of SQL Server is now disconnected from the table, so we are just talking about in-process vs state server.

What are the advantages and disadvantages of each regime in this scenario?

+6
source share
5 answers

Well, the state server is a bit slower than in proc. The advantage that you will get from it is that if you need to process the application pool, then the state of the application (user sessions, etc.) will not be affected. If you plan to use a public server in the future, I would start using it now. At the same time, objects are stored in memory as is, but they are serialized with the status server. This can be a big problem if you plan to turn on the switch later, as you will have to verify that everything you store in state is serializable. If you start with this restraint, you know the front (while you are actively working on this module), what will work and what will not.

+10
source share

I think this is a classic case of YAGNI .

InProc is simple and efficient. If you have a definite need for a separate public service, why would you think of such a change? Indeed, given that the only real advantage is achieved if you distribute your site on multiple servers - and you do not distribute your site on multiple servers, this may be unsuccessful. Even if you are sure that you will eventually switch to several servers, I would not switch until the time comes to load this second server. Read the article on the YAGNI link again to see why.

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

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

+3
source share

I'm pretty good selling, always using StateService, no matter what. We used to use InProc, but it turns out there are (apparently) all kinds of weird ways that appPool can be recycled without your knowledge.

We used to have clients who were losing their sessions, while on the web system once a week or so, due to some inexplicable processing action. When we switched to StateService, we did not have this problem once.

+2
source share

I like to use StateService simply because changing one of them if you ever need to distribute your application through several services. And this allows you to recycle IIS without losing all sessions. Although this is not so useful with just one server, it just seems like nice to have.

My reasons are more general feelings than anything else. But I never had a problem with this.

+1
source share

Correct me if I am wrong, but from what I read there, there is another plus / minus:

  • inproc forces you to use one workflow, thereby losing session state during processing
  • stateerver allows you to use the web garden (i.e. configure the application pool to run, for example, 4 workers).
0
source share

More articles:


All Articles