9

We're currently doing some performance optomisation of our Sitecore 8.1 Website and one of the slowest operations were seeing in New Relic is AcquireRequestState.

I've read around this quite a bit about it (e.g https://discuss.newrelic.com/t/digging-into-the-acquirerequeststate-event/40468) and know that ASP.NET can cause Session Locking and wait for the request to complete before it releases the lock. This can cause significant slowdowns on page load.

I've also read a few Sitecore related articles on this (e.g: https://blog.wesleylomax.co.uk/2015/10/08/sitecore-8-ajax-controller-blocking/) and it looks like it should be possible to disable session on a per Controller basis using:

[SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly)]

New Relic and the article above though suggest that some of Sitecores default controllers can potentially be causing this and not our custom ones.

Has anyone else seen this issue and did you implement this for your custom controllers or patch any out of the box Sitecore controllers?

Further info:

  • Sitecore 8.1 Update 2 MVC
  • 3 front end CD servers (Load Balanced)
  • Session stored out of process in SQL Database
Improve this question
3
  • I've noticed a similar issue on our live environment, we are on SC 7.5 and MVC.NET. The site is hosted on Azure and we have use redis for session caching.
    – Richard Dias
    Mar 23, 2017 at 14:37
  • I've seen infrequent AcquireRequestState issues on my previous live CD of Sitecore 7.2, but never enough to reall dig deep and bother trying to fix it. Recently switched to 8.2 and it seems to be happening a lot more. Not had chance to figure out the exact cause as yet but it's interesting you are experiencing similar issues. New Relic is the source of my information on this, too. I'm getting some traces of 40,50 or even 100+ seconds all caused by AcquireRequestState. What kind of locking times are you seeing? Same ballpark or are mine way higher?
    – theyetiman
    Jun 1, 2017 at 16:51
  • @theyetiman Have you got any feedback from Sitecore on this, its being a while hope you remember what happened! Digging up a bit to troubleshoot some slowness. Using sitecore 8 with similar CD setup as yours with SOLR for caching.
    – Shiham
    Jun 12, 2018 at 2:11

2 Answers 2

Reset to default
3

Session locking only affects requests from a single source. It's more evident in load testing than it is in real world situations, since most of the traffic is coming from a single source, or relatively small number of sources. We have seen performance improvements in code using the ReadOnly attributes for controllers in a load test scenario, but these don't translate to significant gains in live sites.

It does seem that the SessionState acquisition is the first really "expensive" step in the page delivery process since it often involves a connection to a remote service. Stands to reason, then, this is the place we see things "stuck" during heavy load scenarios.

Short of removing session altogether or replacing the process with a much faster model, there's not going to be much can be done about that, I would say.

I've also done a bit of research on this topic and pretty much given up trying to unlock the process here.

Improve this answer
1
  • Thanks for your feedback Richard. I've picked this up with Sitecore Support to see if they can suggest some options as we are using CMS only Mode so can perhaps disable session altogether or patch the default Sitecore Controller. Once I hear more I'll come back on this.
    – Adam Seabridge
    Feb 28, 2017 at 12:30
1

Just to follow up on this there were two things that we did to improve the performance and resolve the problems we were seeing, you may wish to look at these too:

  • Remove/Re-write any Fast Queries you have to use the Search APIs or specific Sitecore Items Id's

  • If using the Translate.Text() or Translate.TextByDomain() this uses fast queries under the hood so re-work how you use this or cache your dictionary items in memory to avoid lots of queries. More info on this here: Sitecore Dictionary Performance question

Sitecore support did say they had an similar bug for SQL session state for 8.1 Update-1.

Improve this answer
3
  • Hi @AdamSeabridge, We are suffering similar problems described in this question. Every hour we have some peaks of time response (Some requests taking about 600s), looking with new relic, most of the time is in the acquire request state. Remove fast queries and not using Translate.Text improve the performance of AcquireRequireState for you?
    – Marc Cals
    Dec 17, 2018 at 13:01
  • Yes from memory those were the key bottlenecks. Are you using fast query?
    – Adam Seabridge
    Dec 17, 2018 at 13:37
  • Yes, but we are removing all from code and we still suffering the same problem, but less often.
    – Marc Cals
    Dec 17, 2018 at 13:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.