MSDN Article By Vishal Joshi
Article Posted: October 21, 2003
It is many a times said that you should use minimum session variables in your web application and use of session variables actually affects the performance adversely. Did you ever try to analyze why is it so? In this article I have explained (in not so detail but have given required operational information) about the Session Variables, their use and their affect on web application performance.
Recollect your writing this simple code int intUserId = Convert.ToInt32(Session[“UserId”]);
Do you know what all does ASP.NET runtime actually does behind the scene? Well in fact to handle this there are lots of considerations taken into account and there is a lot of background processing happening.
To explain this in brief let me re-iterate over the fact that ASP.Net provides 3 different kinds of session storage facilities namely “InProc”, “StateServer” and “SQLServer”. So you can have your session data stored at any of these three different locations.
1. In Process – This is the default option by which the session values are kept alive as objects in Windows Server, by ASP.Net worker process.
2. State Server (Out of Process) – aspnet_state.exe runs as a separate process on the same box or on another machine. In this case the session values are serialized and stored in the memory of this separate process.
3. SQL Server – As the name suggests in this case the session values are stored in the SQL Server table. Again in this case the SQL server can be on the same box as well can be a dedicated DB server.
You can specify the state provider in the web.config file of your application in the section
cookieless="false" timeout="20” />
The mode in the above case can have four different values representing different locations of storage discussed above.
Off – Indicating application wide session state is not enabled. If your application is not going to use any session information remember to set the mode to “Off”. (Note: If you have not set the mode to “Off” and you have a Session_OnStart handler in your application session is saved even though it is empty, which can adversely affect the performance, so do not have Session_OnStart handler unless it is required for your application.)
InProc – This is the default option
StateServer – If you set this as mode then providing stateConnectionString parameter is important. (Note: 127.0.0.1 indicate local host, you may provide any server name, and 42424 is the default port number, providing it is mandatory. Also note that state service, process named - aspnet_state.exe, is installed but is stopped by default, so you may need to start that on the server before use.)
SQLServer – If you set this as mode then providing sqlConnectionString parameter is important (Note: ASP.Net uses default Databases and Initial Catalog so providing such arguments in the connection string is not allowed)
The cookieless parameter indicates whether session without cookies should be used to identify the client sessions or not. The default value is false indicating that cookies should be used to identify client sessions. (Note: This is one of the major differentiating features provided by ASP.NET Session State over classic ASP. In a single line cookieless sessions use mangled URL concept for browsers to identify the session state.)
The timeout parameter indicates the time in minutes after which, an idle user session should be abandoned. (Tip: You may want to take care of this parameter sometimes - like if you are building a catalog or gallery you may not want a user to get time-out notices in a short while but in case of banking application you may want to reduce the limit.)
Now, we understand that ASP.NET can store our session variables at different locations according to our choice, let us now understand roughly what it does behind the scene to get or set our session variables. Take a hypothetical scenario in which you have made no changes to the above settings and a single web page (in consideration) of the web application has got multiple frames. Each frame is reading or writing information into the Session. To add up to the trouble let us assume that only one particular Session Variable is being accessed and modified by all the frames. This scenario is possible right!! ASP.NET runtime needs to handle all such scenarios. To handle this ASP.NET runtime implements LOCK. There are two different types of locks namely - Reader Lock and Writer Lock. If a reader lock is set then concurrent read-only requests will be entertained but write requests will be held back and given last priority. But if a writer lock is set then all the remaining read-only or write requests have to wait. Thus it might so happen that till your one frame finishes the other frames might not even get start their processing. You can see how performance will be affected in this case. Thus ASP.NET implements queuing of requests to session and tries to handle it in an optimized way but we also need to be judicious in requests to the session too!!
Among the available three ways of maintaining session state it is quite evident that InProc mode is the most efficient. Researches have indicated that the use of OutProc (StateServer) mode effects performance up to 15% whereas SQL Server effects up to 25%. The figures indicated by these studies are for basic types and for user defined types they may even go higher. The reasons behind these hits are the serialization and de-serialization that occurs while moving the objects to the session state and then retrieving them. This overhead is clearly saved in InProc mode as the objects are saved in memory and there is no need to go through the serialization/de-serialization processes. The hit that is present in the InProc mode thus is mainly due to the memory consumption by addition of session variables. By judiciously adding objects to sessions thus can help in case of InProc mode.
So now if you ask why we at all need the other two modes when they are so performance expensive then the answer is because of the reliability. The data persisted in SQL Server or in OutProc mode is much safer as it is not hit by failures in IIS or ASP.NET or even by process recycling. Though if SQL Server or aspnet_state.exe is stopped or failed then there are potential chances of the loss of data (in case it is not handled properly!!) but when data is critical then these modes need to be used. So if we rate these modes according to performance then the ranks would be
1. InProc
2. StateServer
3. SQLServer
But if we rate the same from reliability perspective then the ranks would be
1. SQLServer
2. StateServer
3. InProc
Though you can note the ease that the way your application would read/write the data will remain the same as Session[“key”] = value;
Thus again, as usual you have to do the correct trade-off and decide what is good for your application no one can really give a statement on this. But at the first place remember that if you can do away without Session Variables then you should never go ahead and use them.
Now, as we understand the performance implications related to session state usage let us be conscious programmers and understand how we can control sessionState to increase performance of our individual pages. @page directive of ASP.NET page has a property called “EnableSessionState”. If your page is not accessing any session related information you can set this variable to “false”. If your page is going to only read from session then ensure that you set this value to “ReadOnly” and if you are going to do read write operations to session then set it to “true”.
At the end we will conclude by saying that Session Variables are designed for the convenience of us designers/developers but we should be careful enough to use them and should be conscious enough to know how much performance we are trading off by the way we use them.
Vishal Joshi
Microsoft MVP
