Dispatcher Caching: Best Practices for TTL-Based Optimization
Invalidation of the Dispatcher cache is traditionally implied in content publication. Using TTL based invalidation instead shifts control focus and enables decoupling cache hit ratio from editors' activity.
In this session, you will learn,
- how traditional Dispatcher invalidation and TTL based invalidation differ
- how the TTL approach can be applied and what to keep in mind
- how this benefits load distribution over time and content freshness
Plans to add the TTL features of ACS Commons in AEM itself?
When is the "hash"-functionality for clientlibs planned to be ported into AEM 6.5 on-prem? It still isn't there.
I really mean the feature in AEMaaCS, not the one in ACS AEM Commons...
Are there any plans to open-source the dispatcher module? Often we find quirks that are undocumented / not expected behaviour, it would be nice if we could see it / fix it ourselves.
How to deal with concurrent identical requests bombarding Publishers?
A little bit off-topic: When hardening the Dispatcher /filter configuration, you often find yourself wanting to allow a specific selector for a certain (page) resource type, but you don't have that information. How would you solve this gap? We can't predict the content paths authors will come up with and it's very easy to open up a whole lot, for only a few use-cases. The main goal of course being to offload the AEM publish instances, by preventively blocking wrong requests already.
If you have no way of knowing where in a content tree these would appear, then I can't think of any simple way for you to handle this. You'd have to allow the selector. If you can control where in the content tree these are created then you can allow the selector only for that path using the path or url parameter in the filter definition.
Isn't it a viable option to disable Dispatcher caching completely? You are aligning your CDN and Dispatcher with the same TTL's, so when the CDN expires, also your Dispatcher file will expire? This would simplify the setup and you don't have to think about things like grace period
It would create a lot of additional load on the publish instances. In our experience it's appropriate to have that additional layer of caching.
what would an example of that? I’m not familiar with the term
Do you recommend to enable TTL-based Dispatcher when CDN is in place?
What happens when page is updated (TTL expired) and graceperiod is yet not expired?
it will be considered invalid
What if both CDN & Dispatcher TTL expires at the same time? Won’t this cause any performance degradation on publishers?
It’s quite the coincidence and if it happens it’s ok, because it’ll only be a single page. Generally the TTLs add up, as each layer will respect the headers.
Does this also work when you have only infrequent activations? Wouldn‘t TTL be inferior then?
it would still work. you'll potentially lose the benefit of a better CHR, but it would still be smoothed out. after all, it's the peak requests to publish instances you need to size for, so getting rid of the peaks is still cool.
#offTopic Developer used to think a lot about caching strategy in AMS or on premise aem environments. while we are in cloud, adobe already guarantees about sever availability as 99.99%. Also each request is charged no matter whether response is from cache or publisher. This might does not motivate developer to think about caching strategies as he assumes servers to be up and running always?
Caching improves web site response times, so it's not just about server uptime and developers should always consider this, even in AEMaaCS.
Isn't cache warm-up and re-/pre-fetching more important then settings these TTL values?
cache warm-up helps after deployments but doesn't help with cache dips from frequent activations
Why not adding „stale-while-revalidate“ with a short TTL as an performance improvement?
stale-while-revalidate is not currently a supported directive in dispatcher, but we can include this in the header to control the CDN cache.