12

We have been noticing that the first request to any of the Sitecore pages seems to be loaded slow. Every subsequent request is ok.

Note that we can't use output cache as is a transaction based member portal.

  1. What could be the cause and possible solution?
  2. Is there any way to view what's on a pre-fetch cache?
  3. How do we determine the right balance of configuration for pre-fetch cache?
  4. How would prefetch cache work for a scenario where we have multiple CD at any given time (azure scale up/down)?

Background:

Sitecore 8.1 initial release Hosted in Azure Web Apps

Improve this question
1
  • Please post a Trace output of a page that has this behaviour. Pre-fetch caches are rarely the real solution to problems such as this.
    – Mark Cassidy
    Oct 13, 2016 at 23:16

3 Answers 3

Reset to default
17

It could be that you just have a dodgy rendering that is running on every page and is then cached for that page; to see if this is the case you can profile Sitecore pages.

You can investigate this by clicking on the "Debug" option

enter image description here

and scrolling to the bottom of the page to see the speed of renderings:

enter image description here

From here you can either optimise the code, or check out the rendering to see if you can be more aggressive with the cache on the rendering

enter image description here

Improve this answer
4
  • Nice one but ours is transactional membership portal. How do we get around of logging in as actual member as we won't be able to the page as admin user.
    – Nil Pun
    Oct 6, 2016 at 4:51
  • Hmmm not quite sure what you mean - I think you'll need to get in to the desktop at the backend to see these diagnostics, Can you check this in a development environment? Failing that you can consider using SaaS tools such as newrelic.com or datadoghq.com in production to find any code hotspots
    – Steve Newstead
    Oct 6, 2016 at 8:01
  • Do the pages consist of multiple renderings? Is the content in every single rendering entirely unique to the user? I find that hard to believe. For example; your global or footer navigation could be common site-wide, so those modules could probably be cached without a vary by. Even if you have a username in the global navigation rendering you could cache with Vary by User and have it cache the navigation on every page and once per user.
    – Laver
    Oct 13, 2016 at 21:54
  • @SteveNewstead, the problem with transaction site is that in order to view rendering stats the user needs to login as member user name and password. When I use their credential the stats don't come up as they are not a sitecore admin nor their credential is hooked up with sitecore. We use third party for authentication of members.
    – Nil Pun
    Oct 22, 2016 at 21:53
12

Possible answers to 1,2,3...

Sounds like you need to do a bit of tuning on your caches. Sitecore has a number of "admin" pages which help you diagnose problems such as this - you can use the cache admin page to monitor the current size, configured size and vectors of the individual caches, include prefetch. To access this page, browse to http:///sitecore/admin/cache.aspx

From my personal experience, you need to ensure that all caches have plenty of breathing room. If a particular cache runs at ~40mb once your site is up and running, then it is advisable to have a cache size of >60mb. If your caches do not have this breathing space, you will find that they will dump data

If you are using the HTML output cache, there is also the /sitecore/admin/stats.aspx page which will help you determine how well controls are performing.

Please see this blog for more information about Cache Tuning

https://sitecorebasics.wordpress.com/2011/04/16/basics-of-cache-size-tuning/

Answer to number 4...

The prefetch cache is built at application start and maintained for the life of the application pool. Providing each CD has the same prefetch configuration, and cache size configuration, the caches will be identical, so performance differences between them should be non-existent or negligible.

Improve this answer
1

We were facing the same problem every day because of our nightly release cycle. It seems like our application pool went to sleep and had to be woken up before we could use it.

What helped us, was change a setting in IIS to make to application pool react much faster.

If you go to your application pool and right click the particular pool. Choose Advanced settings in the menu. A pop-up will appear, under the sub tree Process Model, there is a setting called:

Idle Time-out Action

Put this to suspend instead of terminate, this should make the response of your site much bigger.

Let me know if this helped you out enough.

Improve this answer
1
  • Not only one page but every page first request
    – Nil Pun
    Oct 14, 2016 at 20:22

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.