How to Store Session Data in ASP.NET State Server

ASP.NET Session State allows four modes to specify where you want to store session data: InProc, SQLServer, State Server and Custom. Default mode InProc, is fastest and default mode, but not useful in many scenarios. One of the significant problems is that sessions stored InProc are deleted every time when application restarts. This could happen pretty often (read Restart and Stop of ASP.NET Application tutorial). If your user was in the middle of long task (like populating long order form or survey; or reading of license agreement etc., all his previously saved session data will be lost, and he or she must start process from the beginning.

One more problem is scalability. Since data are stored in process, server quickly runs out of memory which decreases performances. On high traffic website, session data of thousands users easily overburden web server.

Also, default InProc mode doesn't support multiple servers (web farms) and multiple processors (web gardens). If your website is running on multiple web servers or multiple processors, you have to keep sessions out of ASP.NET process.

As solution for all of these problems, as more reliable and scalable options, ASP.NET introduces State Server and SQL Server. Both State Server and SQL Server stores sessions outside of ASP.NET process, so they are appropriate solution for web farm scenario.

More about storing session data to SQL Server you can read in How to store ASP.NET session state on SQL Server tutorial. In this tutorial, we will take a look to State Server, as some kind of compromise between InProc and SQL Server.

What is ASP.NET State Server?

State Server is implemented as Windows service. File of State Server is aspnet_state.exe. This file is located on [SystemFolder]\Microsoft.Net\Framework\[.Net Framework Version Number]\aspnet_state.exe. Example location for ASP.NET 4.0 could be:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_state.exe

InProc mode works by default and doesn't require any configuration. To implement State Server, you need to start State Server service, change few Windows Registry keys, edit web.config and secure State Server if runs on dedicated machine.

How to use Session State service and web server on same machine?

Session State service uses server's memory to store sessions. If both web server and state server are on same machine, you will not get more scalable solution than InProc is. If there is no enough physical memory, Windows will use disc which drastically decreases performances. Only benefit in case when web server and state server are on same computer, is that sessions will not be lost on application restart.

To implement this option, you need to follow two short steps:

First, be sure that State Server windows service is running. Check in Windows Control Panel --> Services and assure that "ASP.NET State Service" is started. You can also start state service using command prompt with line:

net start aspstate

By default, State Server service is set up to start manually. Change startup type to Automatic so it will run again if computer restarts.

Second step is to edit <sessionState> element in web.config to configure ASP.NET web application to use State Server. Like this:

That is all. Now you can start ASP.NET application and session data will be stored out of application process, in State Server.

How to use Session State on remote machine

Storing session data on remote machine is more scalable option, since web server's memory stays intact and it's not used for sessions.

By default, Session State service will not allow connections from remote servers. To change this, you need to edit value of Registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\AllowRemoteConnections. Default value is zero which means that State Server doesn't allow remove connections. Default value is desirable if you have only one web server and it is on same computer as state server. To allow remote connections, change its value to 1.

Be aware that, if AllowRemoteConnections registry key is set to 1, State Server will talk to anyone, not just your desired web server. Due to security reasons, you have to disallow access from any computer except web servers, especially if State Server is connected to Internet.

How to use Session State server on web farm?

There are additional steps if you use State Server on multiple servers (web farm). You need to check machineKey and application path on each server. You should have same <machineKey> on every web server. Also, application path in IIS metabase should be same on every server.

By default, State Server will listen on port 42424. You can change this port in HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Services\ aspnet_state\ Parameters\ Port registry key. Whichever port you choose, be sure that it is not open for Internet, due to security reasons. State Server should listen only your web servers.

InProc mode allows storing of any .Net type. But, if State Server is used, all objects that will be stored in session variables must be serializable.

Advantages of State Server:

- State Server is more reliable option when compared to InProc. Session variables will remain when web application restarts or get recycled
- State Server supports web farms (multiple servers) and web gardens (multiple processors)
- It is more scalable than InProc. If State Server is on same computer like ASP.NET application, there is no benefit since they both share same memory. But, if State Server is used on separated, dedicated machine, web server memory remains free which increases performances.

Disadvantages of State Server:

- State Server is slower than InProc if you store primitive types (like integers, strings etc.). Also, it requires additional step for serialization/deserialization if you save complex objects in session variables
- Requires additional configuration. InProc is faster for implementation since it works by default
- All sessions are maintained on single machine. This creates single point of failure. If this machine goes down, sessions are lost.
- Session_End event will fire only if InProc is used. This event will not fire if State Server or also SQL Server is used.
- Session State usually is not available on shared web hosting
- Architecture becomes more complex. InProc is practically invisible, it works by default inside process. In the other hand, State Server is one more thing that requires your time and efforts for configuration, management, possible problem solving, administration of additional computer if State Server is on dedicated machine etc.

Common errors when trying to implement State Server

If you have 32-bit version of ASP.NET and 64-bit version of Windows, you can experience "The system cannot find the file specified" error. The problem is that there are two similar folders:

%SystemRoot%\Microsoft.NET\Framework\ and,
%SystemRoot%\Microsoft.NET\Framework64\

The file aspnet_state.exe is located in first folder, but system is looking in second folder. There are two possible solutions:

- You can install 64-bit version of ASP.NET, or
- Change registry key to point to correct folder. Open Regedit and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\aspnet_state. Change key ImagePath to %SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\aspnet_state.exe.

Another frequent problem occurs because State Server doesn't allow connections from other computers. If you have dedicated state server, ASP.NET will return an unhandled HttpException. To resolve this, change value of registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\AllowRemoteConnection to 1.

Conclusion

State Server is somewhere in the middle between InProc and SQL Server. InProc is faster, but less reliable and scalable. On the other hand, SQL Server is most reliable, but the slowest option.

Main reasons for moving from InProc to State Servers are support for web farms, reliability and scalability. Unlike InProc, State server supports web farms and web gardens and variables are not lost when application restarts.

If you store complex objects to session, don't forget that Session Server demands that objects must be serializable. If you have some custom controls or classes, don't forget to mark them with [Serializable()] attribute.

Be aware that Session State is slower than InProc when storing primitive types. For complex types, there is additional step of serialization/deserialization which also takes time and could decrease performances. If possible, consider storing few primitive types rather than storing one complex class and avoid serialization on that way.

There are potential security problems if dedicated State Server is used. Since ASP.NET and Session State communicate without encryption, anyone can read sessions if connect to State Server machine. So, be sure that no one except web servers can connect to State Server.

For websites which don't use sessions much, have low traffic, and pages are not changed often (e.g. content is changed through some content management system, application like blog, forum etc.), InProc mode could be good enough. Session State is more reliable, but often is not available on shared hosting. Most reliable option is to use SQL Server. More about SQL Server option you can find at How to store ASP.NET session state on SQL Server tutorial. Sometimes sessions are simply not enough. More about most recommended alternatives see in ASP.NET Session State Alternatives tutorial.

Happy coding!

Tutorial toolbar: Tell A Friend | Add to favorites | Feedback |