Post navigation

ASP.NET Session State Best Practices

Session state is an integral part of many ASP.NET apps but it can also be a drag on performance or result in application errors if used inappropriately. Here are our ASP.NET Session State best practices to ensure you won’t be tripped up by any gotchas:

Do not overuse Session State for user data storage.
One of the problems with Session State is that it is so convenient for user data storage – just store anything using Session["someName"] = someName.Text . This leads developers to overuse Session State and store data that would be better handled by another technique (for example, you can use ASP.NET Membership Profiles to store and retrieve user settings, or use caching for storing miscellaneous items).

Try to avoid storing complex objects in Session State.
Session Sate can store objects of any type (including objects you create) however, they are stored by serializing and then de-serializing them which results in a big performance penalty. If possible try to only store ‘basic’ types such as Integer, Decimial, String, DateTime, GUID etc

Use an Out of Process mode if possible
Session State provides for three configuration modes – In Process, Out of Process using stateview and Out of Process using SQL Server.
In Process stores the session state data in memory with the same process as the application, this has the advantage of being the fastest mode but it also means that all session data is lost when the app restarts. The app restart is more common than many developers believe, in addition to server and IIS restarts any change in the web.config or global.asax file will restart the app and all session state data can be lost.
Out of Process (stateserver) stores the session data in memory but in a different process, if you are running a web farm this can even be on a separate machine. Out of Process (SQLServer) stores the session data in SQL Server which is the most stable as it will be recoverable in all scenarios except a database failure but it is also the slowest. Both Out of Process modes protect the session data from loss due to an app restart.

Do not store sensitive data in Session State.
SessionID’s which identify user sessions are sent in clear text and can be intercepted by nefarious users. Once a user’s SessionID has been obtained, data stored in the Session State associated with that SessionID can be easily accessed. Thus you should avoid using Session State to store sensitive data or use SSL or encryption of the data to protect it.

Allow users to log out of an application
You should allow users to log out of the app, upon logon the app should call the Abandon method. This will reduce the scope for a malicious user to get hold of the unique identifier in the URL and then use it for retrieving user data stored in session state.

4 thoughts on “ASP.NET Session State Best Practices”

We have 150 session variables for a in house BI app. I have been told this is too many. Is there a best practice as to how many session vars u use? And what info to store in them? Or is there a better way.

150 session variables is definitely a lot but the real issue is how long they will stay in memory for – can they be removed after a short time or do they have to remain in memory for the entirety user’s session?
Two options to consider are Profiles and cookies, both have performance issues however (especially profiles since a user’s entire profile must be read into memory upon each request).
Inproc sessions definitely offer the best performance but with 150 variables you will have to look at the memory allocated per user.

We have set the session time time out to 8 hours. Basically because we have partners of the firm that want to check the data in-frequently during the day. So we don’t want the session to time out and lose their state. When this happens the iframe goes inside out.

We have been told by contractors that 150 session vars is excessive.

Is this true? If so how can we store the session state, an alternative that inclused the user being able to use the back button would be very helpful. We have no idea how to store the session vars so the user can use the back button and go back pages without losing the state

8 hours is a loooooong session time out period, data can easily be lost with a user’s browser restart or a server restart on the web server. It sounds very much a use-case for ASP.NET Membership Profiles – but these should also be used with caution as a large number of Profiles can drain performance since the entire user’s profile is read each time a single profile is accessed.