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

Teriann

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.

Teriann

is this already the default session state provider for a "blank website" created for .net framework 4.6.2 and above? – Palpitant

Unfortunately not. You would still need to change this. If you are hosting in IIS you should be able to see requests stuck in acquireRequestState if you are experiencing this issue. (I'm not sure if there are templates for 4.8 available that has this as the default) – Teriann

Answer 2

I am clear about the acquire state delays - default session provider allows one requests per user at a time, it keeps a lock on session until a request is processed. There are a number of ways to fix the problem, but I understand this is all taken care. I wonder, if anyone had answers for questions 1, 2 & 3.

Aggressive

As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center. – Expletive

This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review – Broeker