If you are running Magnolia in production, sooner or later you will need a Content Delivery Network sitting in front of your public instances. A CDN takes care of caching static assets close to your end users, serving dynamic content from Magnolia public instances and, on top of that, protecting your site with a Web Application Firewall. In this post we will go through how a CDN like Fastly is set up in any Magnolia setup and the best practices around caching.
The big picture
Before going into the details, let's quickly review what sits between the end user and Magnolia:
End users hit the CDN, which either serves a cached response or forwards the request to the load balancer. The load balancer then routes traffic to the Magnolia Author and Magnolia Public instances. The CDN provided by Magnolia DX Cloud is Fastly but you can also bring your own if you already have one in place. In the case of Fastly, it also comes with WAF protection, but lets focus on the CDN for this post.
The goals are simple:
• Cache static content for faster delivery
• Serve dynamic content from Magnolia public instances
• Protect everything behind a WAF
CDN set-up
Setting up the CDN for a project is mostly a matter of wiring a few things together:
• A Fastly service is created together with a WAF site (optional).
• A certificate needs to be uploaded to the Fastly.
• The domain (or domains) needs to point to the Fastly servers.
But lets focus on the Magnolia side of things, what to take into consideration to get most out of the CDN.
Magnolia best practices
There is one thing to keep in mind when working with a CDN in front of Magnolia: caching happens in more than one place. Magnolia has its own backend cache, the browser has its cache, and the CDN has yet another one. The trick is to make them work together and not against each other.
A few rules of thumb we follow:
• Aim for a hit ratio and CDN coverage over 70%. Anything below that and your CDN is more decoration than acceleration.
• Define caching rules for images, REST endpoints and anything else that does not change very often.
• Use cache-control for both the browser and the CDN, and surrogate-control when you want a rule that only applies to the CDN.
• The default rule
cache-control: private invalidates surrogate-control, which is something easy to forget when troubleshooting.• Pages are not cached by default. If you do want to cache them, remove the
dontCachePages rule.• Every URL with different parameters creates a different entry in the CDN cache, so be mindful of query strings.
• Personalization (P18n) creates different cache entries per variation via the
Vary header.Cache config in Magnolia
In config:/modules/cache/config/contentCaching/defaultPageCache you can find cachePolicy and browserPolicy, first one is Magnolia internal caching at server level using Ehcache (not covered in this post) and second one is the one setting cache-control headers.
Lets see an example:
This would set cache-control: max-age=3600, public header for js/css files under /.resources path.
If you want to set cachesurrogate-control headers you would need to add an AddHeaders filter.
More best practices
Once the basics are in place, there are a few extra goodies you can take advantage of:
• A static error page can be configured for 404, 503 or really any status you want.
• Rate limiting and any other custom CDN rule can be added on top.
• Segmented caching for videos can be activated when needed.
Watch out for cookies: any response that sets a cookie will not be cached. The usual suspects in Magnolia are:
• The country trait setting
JSESSIONID• The csrfTokenSecurity filter setting a
csrf cookie• The ingress sticky sessions
If you see your pages stubbornly missing the cache, this is the first place to look.
HTTP statuses cached by Fastly
Not every HTTP status is cacheable. Fastly will cache the following:
• 200 OK
• 203 Non-Authoritative Information
• 300 Multiple Choices
• 301 Moved Permanently
• 302 Moved Temporarily
• 404 Not Found
• 410 Gone
Everything else will go through to the origin.
REST caching
REST endpoints can be cached too, and in most projects they should be: the typical "give me the latest news" or "list of products" endpoint is a great candidate for a CDN cache. Apply the same headers as you would for any other resource and remember that, again, any
Set-Cookie in the response will bypass the cache.Debugging with Fastly
When things do not behave as expected, Fastly gives you a few tools to figure out what is going on.
Fastly cache status
Every cached request comes with a status in x-cache header that tells you what happened:
• HIT → the response was served from the cache.
• MISS → the response was not in the cache yet, but it will be next time.
• PASS → the response is not cacheable and will never go into the cache (usually because of a
Set-Cookie or a cache-control: private).If you expect a HIT and you keep seeing PASS, that is your hint to go and review the response headers coming out of Magnolia.
Wrapping up
A CDN in front of Magnolia is a lot more than "free speed". It is a piece of your architecture that interacts with how you build pages, how you set headers, how you handle cookies and how you secure your site. Spending a bit of time on the caching rules and keeping an eye on the logs pays off very quickly — both in performance and in your end users' experience.
Happy caching!
0 comentarios:
Post a Comment