Entire AEM Dispacher Cache Invalid After Every Page Publish | Community
Skip to main content
S
stuart.mcgarrity
July 1, 2019
Solved

Entire AEM Dispacher Cache Invalid After Every Page Publish

  • July 1, 2019
  • 6 replies
  • 6509 views

Hello,

Our AEM dispatcher cache becomes invalid as soon as any page is (re)published by an author. As we publish pages many times each hour, there is effectively little to no dispatcher page caching, and pages are rebuilt for each request. I can see the effect of this with the marked difference in response time during a period of no author publishing and just after.

Is this expected? Can't the cache be configured so that only the re-published page and those dependent on it are invalidated?

Thanks,

Stuart

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 antoniom5495929

Hi Stuart,

No, this is a very bad practice!

The dispatcher allow you to serve a very large number of request if the page is cached.

If you need to remove all cache for each author page publish, probably you are working on a full loggedin site which need to have really dynamic information. If you are working on a full loggedin site, probably you need to remove the caching directly from the dispatcher configuration; even if I can confirm you that also into some loggedin site (e.g. intranet) something could be cached in order to improve performance.

Let us know if you need more info.

Thanks,

Antonio

6 replies

antoniom5495929
antoniom5495929
Level 7
July 1, 2019

Hi Stuart,

You need to configure your dispatcher in order to align the cache management to your expectation.

Probably in your case you need to change the statfilelevel in order to clear the cache only for the subtree with depth which you decide.

Have a look on this documentation [0] [1] where you can find all the available configuration for dispatcher caching.

[0] Configuring Dispatcher

[1] Optimizing the Dispatcher cache

Let us know.

Thanks,

Antonio

    A
    Community Advisor
    AlbinIs1Community Advisor
    Community Advisor
    July 1, 2019

    The cache invalidation behavior can be controlled by /statfileslevel configuration in the farm file.

    If you want to invalidate only the modified file then send additional Header CQ-Action-Scope: ResourceOnly as part of the flush agent request.

    Regards

    Albin I

      A
      Anonymous
      July 2, 2019

      Looks like you did not configure Dispatcher properly.

        Nisha_Nivedita
        Adobe Employee
        Nisha_NiveditaAdobe Employee
        Adobe Employee
        July 3, 2019

        You might want to revisit the dispatcher cache configuration and check statfileslevel. Having said so , you can also Cache content for as long as possible and reduce requests that go back to AEM - Optimize flush requests by enabling refetching flush on all flush agents.  Use /enableTTL and set Cache-Control: max-age=... header to cache files as long as possible.

        Check doc - Optimizing the Dispatcher cache

          S
          stuart.mcgarrityAuthor
          July 3, 2019

          Thanks all for the helpful information.

          Is there any scenario where you would want to configure the dispatcher to invalidate the entire cache for every author page publish?

          antoniom5495929
          antoniom5495929Accepted solution
          Level 7
          July 3, 2019

          Hi Stuart,

          No, this is a very bad practice!

          The dispatcher allow you to serve a very large number of request if the page is cached.

          If you need to remove all cache for each author page publish, probably you are working on a full loggedin site which need to have really dynamic information. If you are working on a full loggedin site, probably you need to remove the caching directly from the dispatcher configuration; even if I can confirm you that also into some loggedin site (e.g. intranet) something could be cached in order to improve performance.

          Let us know if you need more info.

          Thanks,

          Antonio

            Terms & ConditionsAccessibility statement

            Loading footer...