statfileslevel to a higher number or to the max depth of contents | Community
Skip to main content
V
vsharm3
Level 2
October 16, 2015
Solved

statfileslevel to a higher number or to the max depth of contents

  • October 16, 2015
  • 4 replies
  • 1625 views

Friends,

We have a situation where we statfileslevel is set to "2" in dispatcher.any which invalidates the cache any time there is a page activation happens at /content/<root> level. We have pages very deep in the content tree and do not want dispatcher to invalidate the cache every time a page is activated as it is a performance hit on the publisher to fetch newer contents which have not been modified.

We could set this to a  higher number say "4" or "5" which would reduce number of pages for which cache would be invalidated, but we have pages very deep in the tree (10-15) as well. But ideally we do not want any other page cache getting invalidated whenever we are activating a page.

I am wondering what would be the impact if we set statfileslevel to say 10 or 15? Will it create any issues i.e. performance etc? What should be the ideal settings in this case?

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Lokesh_Shivalingaiah

Actually setting statfileslevel higher will improve the performance as it has to invalidate the less number of files. But however it also depends on how it has been grouped and dependency with the different levels. 

So we need to really look at the folders or level how it has been done and find the right number to set the statfileslevel carefully so it doesnt impact the invalidation of caching

4 replies

Lokesh_Shivalingaiah
Lokesh_ShivalingaiahAccepted solution
Level 10
October 16, 2015

Actually setting statfileslevel higher will improve the performance as it has to invalidate the less number of files. But however it also depends on how it has been grouped and dependency with the different levels. 

So we need to really look at the folders or level how it has been done and find the right number to set the statfileslevel carefully so it doesnt impact the invalidation of caching

joerghoh
Adobe Employee
joerghohAdobe Employee
Adobe Employee
October 16, 2015

Hi,

it highly depends on your content structure. If a change in a page deep in the hierarchy will have an impact on pages which are residing on a higher level, then you should reflect that in your statfileslevel. For example, if you have FAQ pages, and you a page on a higher level, which displays the 3 latest updates to the FAQ pages, then a change to any of the FAQ pages you invalidate this summary page as well. Otherwise your content gets inconsistencies on a content display level.

kind regards,
Jörg

A
Anonymous
October 16, 2015

There is no definitive rule of thumb to get the ideal statfilelevel but rather a judgement based on the content strategy and content reuse (either embedded as a link on other pages or as a hit result of a query) and level of content contribution and activation.

I personally feel keeping a full depth statfilelevel is not a good approach as this would certainly cause a level of staleness in the content served to the users. Again, totally depends if the content updates are not so frequent on your site that such staleness can rather be ignored.

For a typical content structure "/content/<brand>/<region>/<language>" a statfilelevel of 6 is sufficient to hold a good performance benchmarking on a site that has moderate content updates / activations.

If we really think about it, it just need one additional call to the server to re-generate the cache. Also, having a cache refresh at frequent intervals ensures minimal content staleness for the end users.

Hope this helps.

Feike_Visser1
Adobe Employee
Feike_Visser1Adobe Employee
Adobe Employee
October 16, 2015

You can also set the cq-action-scope to ResourceOnly (in the flush-agent).

Then *only* the activated page gets flushed.

https://docs.adobe.com/docs/en/dispatcher/page-invalidate.html

[img]Screen Shot 2015-09-18 at 9.19.17 AM.png[/img]

Terms & ConditionsAccessibility statement

Loading footer...