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 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 (
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.
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.