Question : Intermittent long load time at Session REQUEST_ACQUIRE_STATE

We are having a problem with IIS 7.5.  We are in the process of migrating an existing ASP.NET site to a new server. It was running under IIS 6 just fine for about 5 years.  There no traffic and no processes are running on this new server.  It is an internal website and nothing else has been migrated to this new box, but it is being accessed via the internet and not via a local network.

The site is running with HTTPS required and a self-signed security certificate.  Every several page loads (one in five or one in six), the web browser just spins for about 111 milliseconds.  When trying to figure out what the problem was, we enabled tracing using the web.config file:

 <system.web>
    <trace enabled="true" pageOutput="true" requestLimit="200000000" traceMode="SortByTime" localOnly="false" />
    ...
 </system.web>

Once the trace was enabled, we found that the request never hung.  It always processed within under a second.  We have since tested extensively and found that it consistently hangs when <trace enabled="false" .../>.  When set to enabled="true", the request never hangs.

We tried looking at the request by turning off the trace on the server and turning on Charles (3.5.1) on the local machine.  Interestingly, we do not get any hangs on the site with Charles running either.  The browser never reports any errors, but our application level error trapping (executed from Global.asax in Application_Error) reports an invalid viewstate.  I think the invalid viewstate is unrelated, but who knows.

These pages are data intense, so we wanted to look at that aspect.  We found nothing in SQL Profiler that would indicate SQL Server being involved in the problem.

Next we tried using Failed Request Tracing Rules.  Since the page wasn't reporting an error and just taking way too long to load, we set the condition to Status Code 200.  This successfully recorded the page loads.  Since it was just me on the system, I could easily pick out the good loads from the long ones.

 What we found was a long time on the "Session" "REQUEST_ACQUIRE_STATE" that directly follows the "ManagedPipelineHandler" "MAP_REQUEST_HANDLER".  

Session state is in process and has the standard setup.  Nothing has been modified.  This is a login site using ASP.NET Membership Provider, but otherwise does not really use any session variables.

There are no issues reported in the server's Windows Logs, and no exception seems to be thrown on these long loads.

Does anybody have an recommendations or suggestions about how to resolve this?

Thanks,
John

 

TraceLog.png (87 KB) (File Type Details) 

Trace Log

Answer : Intermittent long load time at Session REQUEST_ACQUIRE_STATE

I don't have any certain answers, but I was able to resolve the problem.  The site in question was running in .NET 2.0 with the older version of the System.Web.Extensions (scripting, JSON and other whatnot).  We were also using the ASP.NET SqlMembershipProvider.  This was also on an HTTPS connection (though whether that was related, we don't know).

In our research we found that turning on tracing via the web.config stopped the problem.  Likewise, using Charles to watch the what was happening from the remote client seemed to stop the problem.  Based on this we figured that it was most likely a client side issue.  The issue never impacted Firefox or Chrome, and we were able to find others with issues where Internet Explorer was not sending cookies or having problems with cookie communication in particular situations.  Knowing that a change on the server (enabling tracing) would stop the long delay from occurring, we reasoned that something in the communication between the site and IE browsers was the problem.

Fix that worked for us:

We upgraded the web.config and the site to use 3.5 of the system.web.extensions section group in the configSections, upgraded the assemblies, httpHandlers, httpModules, and added in the system.codedom, system.webServer sections.  We recompiled the site and redeployed the code to the server and the problem has since been resolved.

I suspect that the addition of the system.codedom and system.webServer was important.  Using the newer assemblies also may have played a role.

Thanks,
John