AcquireRequestState vs PreExecuteRequestHandler

Question

We picked up quite a high number of ajax calls taking a significant amount of time in AcquireRequestState, in our travels we stumbled upon the session locking gem in ASP.Net so we implemented a custom session state handler (Based on link below).

After making the change and deploying it, we saw a very sharp drop in AcquireRequestState but it had been replaced with PreExecuteRequestHandler.

This morning it suddenly dawned on me that we had included OWIN which was probably the reason for the PreExecuteRequestHandler taking up so much time. I then proceeded to remove that and the moment I deployed the code, PreExecuteRequestHandler disappeared off of the list. Sadly, it has now been replaced with AcquireRequestState again at pretty much the exact same cost.

We do seem the be getting hit quite hard on AJAX calls that return Partial views, AJAX calls returning primitive types or JSON objects seem largely unaffected despite higher throughput.

So this leaves me with 3 questions that I am absolutely stumped on and I presume the answer for one would lead us to the answer for the other 2.

1) Why did the cost move from AcquireRequestState to PreExecuteEventHandler when OWIN was installed? Is something on OWIN marked as IRequireSessionState? (It is my understanding that AcquireRequestState should have occurred earlier in the managed pipeline)

2) How do we obtain more information on what's actually going on inside that AcquireRequestState? Or is our time better spent returning JSON object and using that to render what we require on the UI?

3) We do see a couple of requests (very few though) that map to /{controller}/{action}/{id} in New Relic and is then completely stuck for the duration of the request in the above mentioned. This despite setting constraints on our routing to only route to controllers and actions we have in the project.

PS: This does seem very similar to the following, we are also seeing this in New Relic: long delays in AcquireRequestState

Custom Session Module from : I just discovered why all ASP.Net websites are slow, and I am trying to work out what to do about it

Answer 1

For anyone trying to rule out the session problem we ultimately faced above, but who still needs to rely on session values (so you can't just disable the session on the controller level) have a look at the following sessionstate provider:

https://github.com/aspnet/AspNetSessionState

Specifically make sure you pay attention to the following application setting:

<add key="aspnet:AllowConcurrentRequestsPerSession" value="[bool]"/>

You will need to upgrade to .Net Framework 4.6.2 but in our case it's a small price to pay.