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:

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.

As a software engineer by trade, I tend to think about things such as performance being a key factor to the quality of pretty much everything I use. If I go to a website and it takes me 30 seconds to load a very simplistic interface with a few paragraphs of text I tend to get an instant dislike for the application. I know that most users feel the same way. I know years ago in the age of dial up, it was said that if a user ever had to wait more than thirty seconds for a page to load, you had a 50% chance of losing that user on your site forever… My question is what happened to those days of optimization? Was it truly lost with the age of bandwidth? Do we really care about the fancy buttons that much that we've forgotten about writing quality interfaces?

When I recently had the pleasure of working through some old code written a couple of years back by another developer I had a very strange eye opening experience; just how inefficient Server controls can be in .net. This shouldn't be new to anyone really… I mean in the first couple of chapters of my MCTS book it very clearly illustrates that server controls can provide dynamic behavior, and greatly simplify the process of processing the user interaction state of development, but server controls should only be used when this is required. With this rather lengthy introduction, I present to you the most misused server control, the ASP Label.

Microsoft defines the Label Web Server control as having the functionality to "Display static text on a web forms page and allow you to manipulate it programmatically." I use labels all of the time for this purpose, and they work really nicely for it. This however is one of things I do not use a label for:

<asp:Label runat="server" ID="HeaderText" CssClass="H1HeaderText" Text="Static Header"/>

I would instead place something like:

<h1>

Static Header

</h1>

I know what you're thinking, what's the big deal with putting a few extra labels here and there? Well, I was wondering the exact same thing, so I did a bit of a test to prove my point.

I set up two pages, one with nothing but a label that had some text in it, and another with nothing but a span tag with the same text in it. I used a span tag because that is usually what a label will resolve to after being rendered by .net. I than set up a bit of a test using Watin to spin up several threads, and test the performance of rendering that page with a single label tag vs. the one without. After loading and closing each page 100 times, I found that on average it took roughly 100 ms more to load the page with a single label. I did the test again but this time placed two labels on the one page, and two equivalent span tags on the other. I found that it took roughly 200ms longer to load the page with two labels than the page without. That worked out to be roughly 10% of the total rendering time of the page, keeping in mind of course the only thing on the pages was a label.

So, 100ms per label… that's not that big of a deal right? Well imagine a page with 10 form elements on it, a few paragraphs of static text, and maybe a header and footer, this seems like a fairly typical form to me. Say we said that there were 20 labels total that could be converted to their HTML equivalent without losing any functionality. Given that my small experiment is correct, that would mean that 2 full seconds of server processor time could be simply cut, per request. That means that you could improve the efficiency of these pages by as much as 10%, for doing little more than using a control for its intended purpose… It is for that reason I consider the label ASP's most abused Server control.