-->

long delays in AcquireRequestState

2020-02-23 05:55发布

问题:

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.

回答1:

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.



回答2:

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.



回答3:

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://stackoverflow.com/a/55331786/7581050

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.