ASP.NET sessions corrupted under load

Question

We see that under load, the session data becomes damaged or missing, but the sessions themselves remain present.

Our website is hosted on IIS 7 running ASP.Net 4.0 and uses InProc session state in a web farm with a total of 4 servers behind the Cisco ACE Appliance.

At this time, the question is random, we can not reproduce the problem at our discretion. This web application has been working properly for the past seven months.

We understand that Microsoft does not recommend using InProc with web farms, even if sticky sessions are used.

We have a laboratory environment reasonably identical to our production environment, but unable to reproduce it under significant load (we use WAPT).

In our production environment, we tried to isolate only one server behind the load balancer in order to eliminate "server overload" caused by the load balancer itself. However, the problem persists even when running on the same server. We do not see any disposal of AppPool or IIS at all. As standard practice, we recycle production application pools daily at 3 a.m. and enjoy months of uninterrupted operation in the OS.

What is stored in the session is a lot of objects, from simple types (integers and strings), to our entire shopping basket (graph of complex objects) and even an instance of a user control (.ascx). Due to the inability to easily serialize many of these objects, we cannot make the transition to an extraordinary storage session for a reasonable period of time.

Someone suggested trying to hijack an HTTP session using Fiddler. The problem with running Fiddler is that we cannot intentionally reproduce the problem ourselves. Thus, this does not allow us to capture the HTTP trace of the failure event as it occurs. Trace logs from WAPT in our laboratory are likely to provide the same data as Fiddler, but, as I said, we cannot reproduce it there.

I would really appreciate any ideas that everyone might have ...

Answer 1

Based on all the information collected so far here, I am going to answer with a reasonable assumption about what the problem is.

The session is likely to expire.

Utilization of the application pool is not the only thing that can lead to expiration of the session. And, as Hanselman tells you , this is a common occurrence when you combine InProc session control and high volume.

Edit: Take a look at an older IIS6 blog post that describes how to determine the cause of lost sessions like this, especially those that affect specific users, and not just all sessions, how this might happen. The section of interest is right after the Application_End code snippet talking about web gardens. I was looking for newer information like this, and all I could really find was that all the problems concerned answering another question here on SO .