Hi @JBurkhart. Here is the typical response we have with this type of issue:
The AcquireRequestState event is raised after the event handler has been created. This IIS pipeline step occurs when ASP.NET acquires the current state (for example, session state) that is associated with the current request.
The first step is to investigate how the application handles state. If there are methods under AcquireRequestState, it will be necessary to implement Custom Instrumentation for the methods that are being called during that pipeline step which are not currently showing up. The assembly name, class name, and method name of the missing methods will need to be determined in order to add them to an instrumentation file. Unfortunately, we are unable provide any more details since we can’t see into the methods that are being called. Look through the application code for anything specifically related to session state, or anything attaching to a specific handler, to see what is going on.
We recommend examining the 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. One possibility is a third party library that may have wired up event handlers to the event.
If there are no methods under AcquireRequestState, that indicates that there might be a sessions 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. Examining how the application is handling session state on that particular site to see if there are solutions or workarounds could help. It’s possible there might be an alternative state provider.
The fact that in your case it is a WebAPI application, and does not use session state specifically, does complicate the explanation a bit. However, this is not as much a matter of how the application is coded as it is the way the ASP.NET pipeline itself works. Take a look at the link regarding the IIS pipeline as it explains the process of what is done for every request. Whether the application establishes a specific session state or not, my understanding of the request lifecycle is that the state of the session needs to be determined by the ASP.NET pipeline, regardless if there is some sort of session management occurring or not. Specifically for a WebAPI application, if multiple requests from the same source are being made in a serial context in rapid succession, the entire session state check could be what is causing the bottleneck.
Another question I’d want to ask is whether or not these are outgoing requests, and if so, are they made asynchronously? Changing them to async could very well mitigate the issue. If they’re incoming requests, do you have control of the application making the requests? Again, modifying them to be asynchronous could be one solution.
I’m really interested in anyone else providing some insight on this. Often times we don’t really need to think about how our applications send and receive requests, and what the underlying mechanisms are. We just create the code to do what we need and move on. But sometimes not knowing exactly how IIS, the .NET framework, and our code interact can come back to bite us in the backside. I think this might be one of those situations.
The bottom line is that regardless of the fact that session state is not used in the application, the AcquireRequestState segment is being called. The agent just can’t make that sort of thing up. It really comes to narrowing down where it’s happening, then instrumenting the underlying code to find out what exactly the bottleneck is. Then we can work at finding a solution to the problem.
