For those of you who are unfamiliar, the ASP Session object is used to store information about, or change the settings for an individual user. This information is available to every single page in a web application, and is not available across different users (a similar object exists for this, referred to as the server cache). This is usually a great way to keep information about a user, such as their permissions or preferred city without the need to retrieve the information from a database on every single page.
There are five different methods for storing the session information. Those are as follows:
| Mode |
Description |
| OFF |
Simply put, this turns off the storing of the session state.
|
| InProc |
Using this option will store the values of the session object in the same process as the application being run. This is fine for non-critical or applications that are not load balanced but presents a problem when the requests can be split over numerous computer, or if there is a possibility of web server restarts.
|
| State Server |
This is the ideal solution for extracting the session data from the IIS process, as with this option the session database is stored in the server memory in a different process as IIS.
|
| SQL Server |
With this option, the session database is placed in a SQL Database and stored there until it is required. This option is slightly slower than storing the data on the servers memory, but provides the most robust solution as it is easily scaled and is not limited in size
|
| Custom |
This can be whatever you want it to be, as it allows whatever you can think of to be written for storing and managing the session information.
|
In this post, we will be covering the state server and SQL server options in a web farm environment where the requests are split over a number of servers.
State Server:
This method is very similar to the inproc method, except that the session information is extracted from the IIS worker process. By extracting this information, it allows it to be moved to a separate server and utilized remotely from the web farm as shown below:
This has the benefit that it does not matter which web server the user hits, their session information will always be readily available through the state server, which is definitely a benefit. Also, if Web server 2 where to go offline and all traffic where directed to web server 1, no one loses their session information which is critical in some applications. This is not the ideal solution though, as information stored in memory is only temporary and can easily be over written if space needs to be freed up. Let’s say that the ASP State server uses a FIFO strategy as it simplifies the process for understanding:
As more users join the system, they are simply stacked on top in the available memory, without issue. If user 1 requires their data, it is simply retrieved and then re-added to the top of the pile when more information is saved. That is fine as long as there is available memory, but what about a system with mass amounts of data being stored for each user, with thousands of users? What happens when the memory fills up? Simple, something has to go...
I didn’t write the State server from Microsoft, so I cannot be 100% sure this is how it works; but based on some of the problems we’ve had lately with the state server I’m pretty sure that it works in a very similar manner. With this limitation of physical and available memory, we are presented with a more scalable solution, the SQL Server session database.
SQL Server Session Database:
With SQL Server data is written to the hard drive as it is accessed through the database, thus removing the limitation of in process memory which is presented with the State Server method. In addition to this, the SQL Server is resistant to server crashes, as SQL Server can be set up in such a way that there is a failover database. This means that if the first session database goes down for whatever reason, a second could be spun up containing a copy of the data in the first and no one loses their session information:
This is simply not an option with the State server method.
There is one large disadvantage of using a SQL server to store session information, as each piece is written to disk every time it is accessed; it is considerably slower than the other methods. This will vary based on load and configuration but reports online place this at roughly 10% - 25% slower. End of the day there is no perfect solution for every situation, the important part is we research the knowledge required to make the best decision for our situation.