Performance Tip: A Few Words on ASP.NET Session State

Sessions: The Good Part

HTTP is a stateless protocol, IIS treats each HTTP request for a page as an independent request. The server retains no knowledge of variable values that were used during previous requests. ASP.NET session state identifies requests from the same browser during a limited time window as a session. Session provides a place to store values that will persist across page requests. By default, values are stored on the server and will remain in memory until they are explicitly removed or until the Session expires (default duration is 20 mins).

Sessions are identified by a unique identifier (SessionID). When session state is enabled for an ASP.NET application, each request for a page is examined for a SessionID value sent from the browser. By default, SessionID values are stored in a cookie. If no SessionID value is supplied, ASP.NET starts a new session and the SessionID value for that session is sent to the browser with the response.

Here is the typical ASP.NET cookie that you can find in every ASP.NET web site:

Sessions are available for all users and not only connected users. For example, you can store language/settings/TimeZone/… for anonymous session, whereas you can store login/cart/… for registered users. A session is like a cache but per user; we can’t store everything in cookies or reload user’s data in every request, that’s why we also have sessions.

Session Size: The Bad Part

A first and quick good practice is to keep Session Data as small as possible. For example, 5 000 actives Sessions of 100 Ko will need at least 500 MB in memory on the web server. How will IIS manage this? Not very well, in fact. Web/Front-end server are generally medium sized and you can’t assume you will always have 64 GB. Of course, you can store sessions elsewhere (use a separate session state store provider), but the problem will be pretty the same. Try to always store simples objects or primitives types: this will reduce sessions size and calls to sessions (see next section)

Concurrent Requests and Session State: The Bad Part²

Access to ASP.NET session state is exclusive per session, which means that if two different users make concurrent requests, access to each separate session is granted concurrently. However, if two concurrent requests are made for the same session (by using the same SessionID value), the first request gets exclusive access to the session information. The second request executes only after the first request is finished. 10 years ago, it was not a real problem but now with many AJAX requests per page, live interfaces, multi-tabs browsing, it is really easy to have bottleneck in our systems and performance issues at the client side.

Demo

I will show how concurrent requests can hurt performance in the MVC 4 standard template.

Here is a simple Action in my HomeController. On the other part, I will invoke this action every 10 seconds with an AJAX call in this way:

With a single opened Tab, here is the network traffic:

With 3 opened Tabs, here is the network trafic from the first tab:

It’s the same action! But because of exclusive locking, the time to call the MVC is longer. You can try by yourself, it is really easy to test.

There are many ways to solve this problem and this really depends on your code.

• Do not use ASP.NET Session if it is not required. Session should be used for activity data such as cart. In the past, I’ve seen too many undesired properties like IP, IsLogged, User Address, …
• Change the default SessionStateBehavior for your Controllers. Simply decorate your controllers (or a BaseController) with SessionStateAttribute and apply either ReadOnly or Disabled. Many of your actions can require session but only a few will write something in session state.
  Note: You must explicitly add an attribute to the controller. Even if it seems you don’t use Session state, ASP.NET internals will acquire exclusive lock during requests. It’s the default behavior.
  C#

  [SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly)]
  public class HomeController : Controller
  {..}

• Use a REST-like service like ASP.NET WebAPI or WCF REST. Because REST is stateless by nature, using session state is prohibited.