adobe / aem-dispatcher-experiments Goto Github PK

Customers might have complicated deployments where content may refer to other pieces of content, such as a Page might depend on a DAM asset. There's a way of controlling the dispatcher cache by leveraging the statfileslevel property to invalidate the cache when an ACTIVATE occurs however we may not want to invalidate the entire cache, or large portions of the cache when only a few resources need to be purged.

For example, if a website section /content/my-site/us/en/products leverages images from /content/dam/products, anytime an image asset in /content/dam/products is updated, we want to ensure any uses of it by web pages in /content/my-site/us/en/products are also updated. We could set a stat level of 1 that invalidates everything under /content when anything under /content changes, however this inefficient, since an update to /content/my-site/us/en/products would invalidate everything under the rest of the web site too, for example: /content/my-site/us/en/services and /content/my-site/us/en/about-us, etc.

This experiment would be to introduce an OSGi property to specify a targeted flush rule. By creating a new sling:OsgiConfig node for each flush rule set, this gives more control over the cache flush operations.

See https://adobe-consulting-services.github.io/acs-aem-commons/features/dispatcher-flush-rules/index.html for additional details.

It would be good to show how the value of DispatcherPassError set to 0 can impact performance.

Experiment will demonstrate the effect of using SDI to allow for better page caching with small dynamic elements.

Original source (thanks Tad!): https://twitter.com/TurboDad/status/1294290791032999936