Minimizing Session State

In this section, we’ll highlight the performance tradeoffs inherent in your three choices for using session state services. (We covered session state in detail in Chapter 6.) We’ll also talk about a couple of ways to maximize performance. The three options for session state are inproc, out-of-process, and SQL Server. Inproc refers to session data being stored directly in the same address space as the worker process. This is the fastest option of the three for utilizing session state services. No process hop is required, and object references can be held directly. To use session state effectively in a Web farm scenario requires session-to-machine affinity. The load-balancing technology must be able to recognize the session cookie or browser source address on subsequent requests and have it handled by the same server, which can have performance implications. Fundamentally, it complicates effective load-balancing because the option to utilize the least busy machine is compromised.

Out-of-process state management can be used in a Web farm scenario but the ASP.NET run time must serialize all session data between process and even machine boundaries to communicate with the separate session state process. This option scales well but is still limited by the memory constraints of the state service process.

Using SQL server scales beyond the process limits of the out-of-process state service, but it has the biggest cost to performance of the three options. ASP.NET must serialize the session data to store it out-of-process or in SQL server. For the simple types, like strings and numbers, the serialization is relatively fast, but extra overhead is associated with serializing arbitrary user objects.

Generally, even when using in-proc session state, storing data in session has a cost. Still, it can make a world of difference when writing rich Web applications, so use it but be aware that everything stored in session takes up memory and won’t be released until the session expires. When storing large amounts of data in session, consider reducing the SessionState timeout attribute from its default of 20 minutes to a smaller number.

When the ASP.NET run time manages the Session object, the processing of each page has associated overhead. If session is not being used in your application, turn it off. Code Listing 9-6 disables session state functionality at the application level. If any page tries to use the Session object, an exception will be thrown.

Code Listing 9-6: No Session State Web.config

 <configuration>
    <system.web>
        <sessionState mode="Off" />
    </system.web>
</configuration> 

If a subset of pages in the application utilizes session state, session state can be turned off globally and then enabled only in the pages where it is needed. The Page directive includes the EnableSessionState attribute, which can override the global application setting. Code Listing 9-7 turns on session state and simply stores the time of the request for later use.

Code Listing 9-7: EnableSessionState.aspx

 <%@Page EnableSessionState="true" %>
<script runat="server" language="C#">
protected void Page_Load(object o, EventArgs e) {
    Session["enableSessionStateTime"] = DateTime.Now.ToString();
    theLabel.Text = (string)Session["enableSessionStateTime"];
}
</script>
<asp:Label runat="server"  /> 

Finally, there is a potential for race conditions when accessing session data simultaneously from multiple browser instances or when using client-side frames. To manage this, ASP.NET imposes some reader and writer locking semantics around access to session variables. If a page is accessing session state but not storing any new or updated values in session, use the EnableSessionState Page directive to enable session state for read-only access. This causes ASP.NET to use a reader lock for session access on the page, which can provide a performance boost. Code Listing 9-8 retrieves the time stored by the EnableSessionState.aspx page and displays it but has read-only access to the Session object. Any attempt to write results in an exception being thrown.

Code Listing 9-8: ReadOnlySessionAccess.aspx

 <%@Page EnableSessionState="ReadOnly" %>
<script runat="server" language="C#">
protected void Page_Load(object o, EventArgs e) {
    string theTime = (string)Session["enableSessionStateTime"];
    if (theTime != null) {
        theLabel.Text = theTime;
    }
}
</script>
<asp:Label runat="server"  /> 

Judicious use of session state avoids the need to put everything in hidden fields and have it carried back and forth between client and server, but once again there is a cost. Examine your application and deployment architecture and pick the session state mode that will satisfy your application needs without sacrificing performance.