Managing Performance using Out-of-Process Session State

Out of process session management becomes necessary when deploying ASP.Net web application in a NLB or Web warm. As well sometimes developers do you SQL server for session management because it is a more robust state management option and has more persistence than a memory-based state server. SQL Server option also allows for state to be maintained even across server reboots, because the data for the session persists into SQL Server.

However there can be a serious performance  degradation if developers do not tune the application while using Out of Process session management. By default, ASP.NET assumes that every page requires session state to be loaded during page initialization and to be flushed after the page has finished rendering. When using out-of-process session state, this means two round-trips to the state server (or database server) for each page rendering. But with a careful design potentially many of these round-trips can be eliminated. The idea is to direct the session manager to determine when session state must be retrieved and stored by querying the current handler’s session state requirements. There are three options for a page (or other handler) with respect to session state. It can express the need to view session state, to view and modify session state, or no session state dependency at all. When writing ASP.NET pages, express this preference through the EnableSessionState attribute of the Page directive.

<%@ Page Language=”C#” AutoEventWireup=”true”  CodeFile=”Default.aspx.cs” Inherits=”_Default” EnableSessionState=”ReadOnly” %>

The possible values for EnableSessionState are:

  1. True
  2. False
  3. ReadOnly

This attribute defaults to true, which means that session state will be retrieved and saved with each request handled by that page. If we know that a page will only read from session state and not modify it, we can save a round-trip by setting EnableSessionState to ReadOnly. Furthermore, if we know that a page will never use session state, we must set EnableSessionState to False. Internally, this flag determines which of the tagging interfaces the Page class will derive from (if any). These tagging interfaces are queried by the session manager to determine how to manage session state on behalf of a given page. Thus setting this tag carefully can boost the performance of the application significantly.


One Response to “Managing Performance using Out-of-Process Session State”

  1. Mark Cohen Says:

    I read somewhere that there is a 40% overhead if you use sql server for session state instead of inproc (ram). But that’s 40% of a very small number so I’m not convinced that it is that significant an overhead for most applications. when I’ve used sql session for less-than-trivial applications I have always reviewed performance on the sql database and found it could be hugely improved with the creation of a few indexes. The stock-standard script that MS ships could definitely be improved upon by including some indexes and maintenance jobs

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: