Digging into the AcquireRequestState event

Many customers have written in wanting to see more visibility into AcquireRequestState as they notice slowness in their transaction traces.

This IIS pipeline step occurs when ASP.NET acquires the current state (for example, session state) that is associated with the current request. The session state typically contains information about the user as they navigate the site. If the application is having a difficult time acquiring the session state, it will keep trying until it can either connect with the session state or until it times out.

If there are no methods under AcquireRequestState, this indicates that there might be a session state issue that is taking up a large amount of time. This may not be occurring all the time, but can occur enough to push the average timing up quite a bit. We suggest examining how you are handling session state on that particular site and see if there are solutions or workarounds that could help. You may be able to find an alternative state provider. It is also possible that there may be Session Locking occurring, which is explained in this StackOverflow article.

Here is a hypothetical scenario:
Imagine a user clicks a link twice in a row on accident. This results in their browser making two requests, back to back. Imagine the request normally takes 5 seconds to process. The first request will start and take 5 seconds to process. The returned result will be ignored by the browser because it is waiting for the second request. The second request will have to wait for the first request to finish before it can even start processing the request. This means the second request will take 10 seconds to complete, with 5 of those seconds being spent in AcquireRequestState. Now imagine that after 4 seconds of waiting the user gives up and clicks another link on the page. This new link normally only takes 1 second to process, but it is backed up behind the remaining 6 seconds on the second request. So they won’t get a response for another 7 seconds, with 6 of those seconds in AcquireRequestState. After 4 seconds the user gives up and in frustration clicks on a bunch of different links all over the page hoping something will work. All of these requests will back up against each other and the last one will take however long it took to process all of the previous requests plus itself! This last request will show up in New Relic as the slowest with almost all of its time in AcquireRequestState because the request was blocked on trying to get the session state for the user making the request.

Since AcquireRequestState is a pipeline event, it can be difficult to know what methods to instrument because anything can tie into the event. While some have had success with implementing custom instrumentation, many times it can be impossible to drill down into the root cause.

If there are methods under AcquireRequestState, you will need to implement some Custom Instrumentation for the methods that are being called during that pipeline step which are not currently showing up. This is why you may see in the New Relic UI when looking at a stack trace on an example of a slow response: “Application code (in AcquireRequestState)” and then a note about how you need to add custom instrumentation to get deeper visibility.

We also recommend examining your use of or additions to the AcquireRequestState pipeline step/event handler, as well as how the application handles session state in general since this event is where session state is picked up. Somewhere in the code or within the sessions state provider, something is being used that is getting hung up. We don’t interfere with this part of the pipeline, but rather subscribe to it so that if we instrument some methods within it, they can be associated to it. Check out this reference to a technique that might be helpful in seeing subscribers to an event. This could perhaps identify any third party libraries that may have wired up event handlers to that event.

More than not, time spent in this pipeline event will be associated with how your state provider handles session data (if at all). Identifying how you are managing session variables will be important and there are a number of ways sessions can be configured as referenced here.

Determining how you are handling session state on your application and uncovering if there are solutions or workarounds will be the most helpful. You may be able to find an alternative state provider. Is making your application overall less dependent on session state the solution? That ultimately is your decision. Here is another article with some interesting conversations surrounding that very topic.

I hope this post has been helpful and provided a bit more insight into AcquireRequestState when analyzing your application and trace details.

More helpful links:

IIS 7.0 - https://msdn.microsoft.com/en-us/library/bb470252.aspx
IIS 5.0 and 6.0 - https://blogs.msdn.microsoft.com/tom/2008/05/27/asp-net-application-life-cycle/


A post was merged into an existing topic: Relic Solution: Digging into the AcquireRequestState event