long delays in AcquireRequestState
Asked Answered
C

3

31

Using performance monitoring tool "New Relic" I am seeing occasional (but too many) long delays in the "AcquireRequestState". I am talking about 10, 20 second delays, sometimes minutes.

I know we have not written our own event handlers for this event.

Where do I even begin looking for the cause of these delays? The little information I have found so far on msdn has not been helpful.

Chiropody answered 6/5, 2015 at 3:23 Comment(4)
Hi, did you make any progress on this? We are encountering the same issue, as reported by New Relic.Hopson
Us too. @TomHall have you found any solution? We are seeing the "AcquireRequestState" delays only for AJAX calls, you?Botulin
We are seeing it not only for Ajax requests - but somewhat randomly. Annoyingly New Relic seems to group GET and POST requests together if the base URL is the same. For now we have resorted to our own more granular, internal logging to investigate.Hopson
Assuming this is asp.net, this can be a symptom of using Session and users using multiple tabs, or multiple AJAX calls at the same time. If for example a user runs a long running report in one tab any other requests the user attempts to make will be locked at the "AcquireRequestState" until the 1st tab completes. Here is a better write up on it linkHither
D
10

My team saw this "AcquireRequestState" delay reported by NewRelic earlier today when one of our ASP.NET applications was having performance problems on a particular page.

The root cause turned out to be a change to a stored procedure that we'd recently deployed to our SQL Server database, which was inadvertently causing that stored procedure to take a very long time to execute. The stored procedure was called as a part of displaying the page that was having the performance issue.

We were able to resolve the issue by identifying and fixing the performance problem with the stored procedure. The "AcquireRequestState" issue from NewRelic turned out to be irrelevant; it was a symptom of the problem, rather than the cause.

This was on an ASP.NET 4.5 application running on Windows Server 2008.

tl;dr: The "AcquireRequestState" delay reported by NewRelic may be a side effect of some other problem that's causing one or more of the pages and/or AJAX requests in your ASP.NET app to take a long time to load.

Deter answered 3/6, 2016 at 18:35 Comment(2)
Was the proc invoked during AcquireRequestState @JonSchneider?Gladiatorial
I think the answer was "no", but unfortunately this was a couple of years ago and I can't remember 100%!Deter
R
5

Try to apply Hotfix Rollup 2828841 on the server.

Issue 6

Symptoms

When you send many concurrent requests that have the same SessionId to an ASP.NET 4.5 web application, some requests may freeze at the RequestAcquireState stage unexpectedly.

Resolution

After you apply the hotfix, the hotfix makes sure that the EndRequest event will always trigger.

This hotfix applies to Windows 7 Service Pack 1 (SP1), Windows Server 2008 R2 SP1, Windows Server 2008 Service Pack 2 (SP2), and Windows Vista SP2.

Rosenwald answered 25/8, 2015 at 8:3 Comment(1)
I'm assuming newer OS version's dont require this hotfix?Gladiatorial
H
1

I suspect your stored proc change might be highlighting a slightly different problem in terms of session locking, we had roughly the same being reported for a different scenario, I'd seriously like to encourage you to test out the async session provider as mentioned here and making sure you use the concurrent requests per session app setting :

https://mcmap.net/q/471855/-acquirerequeststate-vs-preexecuterequesthandler

Ultimately any long running process (in your case the stored proc change) is blocking any further requests for that session. Since this "block" is happening in a different part of the IIS pipeline, NewRelic simply records it as "AcquireRequestState"

PS: I know this answer comes quite late but I've finally found something that solved a similar problem for us and I suspect will help many people in the future.

Herder answered 25/3, 2019 at 5:46 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.