ASP.NET Concurrent Ajax Requests and Session State Blocking

Intro

Today I ran into a pretty interesting and puzzling issue while trying to load many different long running content areas on a screen asynchronously via Ajax & jQuery.

It appeared that if I shot off Ajax Request A, B, C, D… that they would always return one after the other (roughly). They never deviated from this pattern and were not appearing to be operating asynchronously from an ASP.NET perspective. To try to figure out what is going on here consider the following C# and JS code:

Example Code

public class TestController : Controller
    {
        public ActionResult Index()
        {
            System.Threading.Thread.Sleep(10000);
            return new EmptyResult();
        }
    }

$(function() {
    for (var i = 0; i < 10; i++) {
        $.get('@Url.Action("Index", "Test")')
    }
})

Check out what (unexpectedly) happens in Firebug’s Net tab:

Firebug Behavior… What?

It appears that my Thread.Sleep of 10 seconds is causing each request to return one after the other (apparently ASP.NET is queuing them differently than Firebug did here in this example), but only after the previous request in the queue has completed. The 10 requests actually completed in almost exactly 100 seconds, as expected given this behavior.

Upon seeing this issue I was initially very confused and began to question my core  ASP.NET understanding such as: is ASP.NET blocking other requests simply because of this Sleep()? Shouldn’t ASP.NET be spinning up other threads to deal with the concurrent request load up to the configured limit?

An Answer, Straight from Microsoft

Luckily it turned out to be something I have never encountered (but I bet people will be seeing more of as the web goes Ajax) Session State blocking! Take a look at the Microsoft Session State article bottom of the page called Concurrent Requests and Session State, let me sum it up:

• Only one request at a time may have Read/Write access to a particular session (as determined by session id cookie) at a time. R/W access is default
• Any additional requests requiring ANY session access will be blocked until the previous R/W request has completed

Why?

Well then… it looks like when ASP.NET was written (over 10 years ago now right?) concurrent ASP.NET processed requests (as opposed to static files) almost never happened as Gmail didn’t make its big Ajax foray until 2005. I’m guessing this behavior exists because because you can get into some interesting situations when it comes to merging written session data keys across multiple possible concurrent requests. I think this might be worth revisiting now in 2011 and allowing for something like “last wins for the same session key”. There are other situations that could occur but I’d rather read some documentation about the expected behavior (with do’s and don’ts) rather than have this occur. Luckily there is a less elegant but workable solution for MVC for right now:

A Solution for MVC 3

Luckily Microsoft has provided ENUM values in System.Web.SessionState.SessionStateBehavior that allow us to give up rights to an exclusive session lock. Mainly the values:

• ReadOnly – Doesn’t block other requests because this request can’t update session
• Disabled – Can’t block, and your best option for performance in StateServer & SQL modes because no serialization needs to occur. Remember that all of session is serialized and de-serialized per user every time. Not just particular keys your are accessing.

Throw a new for MVC 3 attribute with your desired Enum value on your Controller class as such:

[SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly)]
    public class TestController : Controller
    {
        public ActionResult Index()
        {
            System.Threading.Thread.Sleep(10000);
            return new EmptyResult();
        }
    }

(It’s too bad you can’t do this at the action level. My initial thought is that is too late in the ASP.NET pipeline events once Action discovery occurs unfortunately)

Now take a look at our Firebug Net tab (that’s more like it! but what about that light brown bar…):

Browser Concurrent Request Blocking

Browsers limit the concurrent connections per server that can be used at a given time. I have read this is to be nice, to developers and server admins maybe? The brown bar in Firefox indicates a request that is being blocked until the connection frees up for another request. This can be changed by editing configuration entries but it’d be tough to ask for that on a publicly facing website!

Conclusion

Hopefully this helped you diagnose some odd Ajax performance issues! I know the solution isn’t really ideal if you wanted to update session. I find the more I develop web applications the less I use session in favor of using the DOM, jQuery Data, JSON etc, but that certainly doesn’t work for everything! I’m thinking I might explore the possibility of a “MergeSessionStateProvider” if the proper ASP.NET hooks are there to implement it. I think given where the web is going something like this might be becoming more and more critical for the best possible user experience.

Thanks for reading!