Welcome to part 14 of my tour through ASP.NET 4.0. In this episode, we're going to look at two new features Microsoft have added to the way we can control ASP.NET session state. If you choose to use them, they will definitely improve the perceived performance of your session state provider and therefore your application.
Arguably the easiest way to improve session state performance is not to use it, or at least to put as little in it as absolutely possible. However, sometimes that's just not possible. Even some Microsoft teams use perhaps a bit more than they should - the Office Web team stick Word files in session state for example - so we're not the only ones who do it. The problem then is that performance suffers as session info runs over the network between the database storing the info and the web server and then onto our users.
The first of the new features in ASP.NET 4.0 is to make use of the compression features in .NET and apply them transparently to all the serialized session state on the fly as it goes between the web server and the out-of-process state server.
"Anecdotal evidence suggests that this [trade-off between CPU time for network bandwidth] provides reduction in size of between 33% and 66%." - Stefan Schackow, PDC 2009
All you need to do to switch session compression on is set the following config.
<sessionState compressionEnabled="true" ... />
Just to reiterate, session compression doesn't apply to in-process session state but applies equally to the SQL Server provider for out of process session state and the out-of-process state server provider. If you've never considered or simply never needed to work with an out-of-process state server, why not give it a try? Some say that they always go straight to out-of-process - your mileage may vary. Should you wish to investigate further, here are a few good links.
Ever wondered how ASP.NET actually determines whether session state should be used for a page? Me neither. All we really need to know is that we set a default for the Session State module in web.config - enabled, read-only or disabled and then use the @Page directive's EnableSessionState attribute to override that default as required.
However, this is all declarative. What we've been unable to do from v1 to v3.5 SP1 is to override and set the current mode for the session state server programmatically. This now changes in v4 where we can set a new value in the HttpContext that says what mode it should be. Simply create a new HttpModule and hook the BeginRequest event. It has to be this early so the change can be set and ASP.NET will notice the change.
public void Init(HttpApplication context)
context.BeginRequest += new EventHandler(OnBegin);
private void OnBegin(object sender, EventArgs e)
HttpContext c = (sender as HttpApplication).Context;
The SessionStateBehavior enumeration has four possible values. Three of them - Required, ReadOnly and Disabled - set the state server mode and override the value of any EnableSessionState attribute in your @Page directive. However, the fourth value - Default - sets the state server mode to that declared in web.config and allows overrides from your @Page directives, just as it did in previous versions of ASP.NET.
In case you were wondering how session state does work, the session state module inspects the HTTP headers for each incoming request for a 'marker interface' which it then interprets as session state being required or read-only. If it's not there, session state is read as disabled. Hence the problem with setting SessionStateBehavior programmatically - the mechanism has to work over the top of those interfaces rather than manipulate them - they are interfaces so there is nothing to manipulate.
In this episode, we've looked at two new features of ASP.NET for dealing with session state servers - session compression and the ability to set their behavior programmatically. Touted as a post-RTM release, much like the new OutputCache providers mentioned in Part 13, Microsoft also plan to release a new partial session state provider which allows you to state which items in session state should be downloaded from state to web server for any given page being requested. However, that's for investigation after April 12. So for the meantime, happy coding!