Expand my Community achievements bar.

Guidelines for the Responsible Use of Generative AI in the Experience Cloud Community.
SOLVED

Disabled cache invalidation for content fragments?

Avatar

Level 3

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?

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

@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

View solution in original post

9 Replies

Avatar

Community Advisor

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

Avatar

Level 3

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

Avatar

Employee Advisor

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

Avatar

Level 3

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. 

Avatar

Community Advisor

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-c...

Avatar

Level 3

Thanks for the response, will check the documentation. 

Avatar

Community Advisor

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....


Aanchal Sikka

Avatar

Level 3

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? 

Avatar

Correct answer by
Community Advisor

@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