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?
Solved! Go to Solution.
Views
Replies
Total Likes
Ideally yes they should be cached.
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.
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.
Thanks for the response. We will lose last replicated/published date if we install the package on publish instead of replicate. Thoughts?
This is expected, as you are updating a lot of individual assets. What is the behavior you are expecting in this situation?
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.
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...
Thanks for the response, will check the documentation.
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.
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?
Ideally yes they should be cached.
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.
Views
Likes
Replies