Disabled cache invalidation for content fragments? | Adobe Higher Education
Skip to main content
Level 3
June 9, 2023
Risolto

Disabled cache invalidation for content fragments?

  • June 9, 2023
  • 4 risposte
  • 2268 visualizzazioni

We are programatically replicating an AEM package from author to publish. The package contains content fragments under DAM. Just after this replication action, we are seeing 1000s of cache invalidation request being sent to dispatcher via publisher. 

 

It is causing heavy load on publishers. How can we stop this automated dispatcher cache invalidation requests on publish instance?

Questo argomento è stato chiuso alle risposte.
Migliore risposta di aanchal-sikka

@beast42 

 

Ideally yes they should be cached.

  • As part of html, if a component uses CF to display.
  • As json, if GraphQL is used.

They are not cached individually, But, they affect the pages/json that they supply the information to.

Caching reduces load on publish and improves performance. So, unless needed otherwise, we should cache them.

4 risposte

EstebanBustamante
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
June 9, 2023

I think you can do any of below:
- If possible, I think would be better not to replicate the package but install the package in publish instance, this will reduce your network latency as well as will resolve your issue

- You could disable the Flush Agent till the replication process is complete and then re-enabled it.

- You could create your own Flush Agent to avoid those paths based on some conditions.

Esteban Bustamante
beast42Autore
Level 3
June 12, 2023

Thanks for the response. We will lose last replicated/published date if we install the package on publish instead of replicate. Thoughts? 

joerghoh
Adobe Employee
Adobe Employee
June 10, 2023

This is expected, as you are updating a lot of individual assets. What is the behavior you are expecting in this situation?

beast42Autore
Level 3
June 12, 2023

We are programatically fetching content of this content fragments in sling models and I think content fragments are not cached in dispatcher anyways. 

I was just wondering if we can disable the cache invalidation trigger on publish instance for these content fragment paths. 

DPrakashRaj
Community Advisor
Community Advisor
June 11, 2023

It seems with publishing the node from author to publisher it’s calling the auto invalidate feature of your aem dispatcher which also depends on the statfilelevel . 
please check this document to understand the statfilelevel and invalidate section https://experienceleague.adobe.com/docs/experience-manager-dispatcher/using/configuring/dispatcher-configuration.html?lang=en

beast42Autore
Level 3
June 12, 2023

Thanks for the response, will check the documentation. 

aanchal-sikka
Community Advisor
Community Advisor
June 11, 2023

Hello @beast42 

 

When a content fragment is published, AEM automatically trigger Dispatcher Flush. In your case, its the package publish. 

 

Few questions:

1. Does your package only contain updated content fragments, or it is an entire folder?

2. Could you possibly use [0] to create package of only update CF and publish those? That should hopefully reduce the replication events.

 

[0]: https://adobe-consulting-services.github.io/acs-aem-commons/features/packagers/query-packager/index.html

Aanchal Sikka
beast42Autore
Level 3
June 12, 2023

Thanks for the response. 

Package contains all the fragments under a specific DAM folder.  I will explore the idea of creating package of just updated fragments and leverage ACS commons packager. 

One question: Are content fragments cached in dispatcher under any scenarios? 

aanchal-sikka
Community Advisor
Community Advisor
June 13, 2023

@beast42 

 

Ideally yes they should be cached.

  • As part of html, if a component uses CF to display.
  • As json, if GraphQL is used.

They are not cached individually, But, they affect the pages/json that they supply the information to.

Caching reduces load on publish and improves performance. So, unless needed otherwise, we should cache them.

Aanchal Sikka