27 May

Magento Full Page Cache

I find myself talking about this a lot, so here are my musings on Magento and Full Page Cache, written down.

To run at scale, and keep 90% of the load away from your CPUs, you just have to have a Full Page Cache that works. A quick way to test is to measure the Time To First Byte. If FPC is working, your TTFB should be around or under 100ms (not including network latency) after about 2-3 requests.

From an SEO and Customer perspective:

Important: Before thinking about Full Page Cache, you do still need reasonable performance without it. Otherwise you’re really just masking other problems and your customers are going be less than satisfied when they hit a page that isn’t cached.  If your TTFB is much more than 1 second, you first need to talk to your developer and/or hosting provider about optimisation and config.  Additionally, this absolutely does not negate the need for a good cache backend, like Redis.

Full Page Cache is the icing on what should already be a tasty cake.

 

Magento 2.x

Magento 2.x has Varnish 3/4 support out of the box, and it’s recommended over Redis as a Full Page Cache.

  1. Install Varnish, and have it listen on port 80 in front of Apache/nginx.
  2. Configure Magneto to use Varnish, and export a VCL.  Stores > Settings > Configuration > Advanced > System > Full Page Cache. 
  3. This should create a Varnish VCL under <Docroot>/var. Configure Varnish to use that.
  4. If you have multiple web servers, you need to:
    • Ensure your local network range is included in acl_purge{} in the Varnish VCL.
    • define an array for http_cache_hosts in the app/etc/env.php configuration

Enterprise Edition 1.x

In Magento Enterprise, you just turn on Full Page Cache, under System > Cache Management. Simple as that! If your developers advise that it needs to remain off for X functionality to work, then get better developers.  If the TTFB is still slow after 3 or 4 requests, despite FPC being turned on, then it’s likely that a third party extension is preventing content being cached (or immediately invalidating the FPC entries). Engage your developers about this.

As far as the config goes, you can use the local.xml to configure <full_page_cache> independently from <cache> . Use a second Redis instance if you get plenty of traffic; it’s nicer for sys admin management and gives you an extra thread.

Community Edition 1.x

Third party code

As with most Enterprise features, there are plenty of Community extensions to replicate Full Page Cache. Usually though, you need a skilled Magento developer for good integration. In the case of FPC, it’s likely you’ll need to work on your templates for dynamic block placeholders.

Gordon Lesti’s free module is popular; Extendware, Mirasvit and Brim have good solutions for a small fee; there are countless others to choose from. If these extensions work for you, they’re often a great balance between performance and complexity.

UPDATE: Full article on how to configure Mirasvit FPC. It’s one of the best.

Varnish

Instead of a code-based FPC, it’s possible to use Varnish. Varnish can be insanely fast, but you need Magento extension to integrate and manage it properly. Amongst their weaponry are such diverse elements as setting the right cache-control headers, TTLs, purging expired content, and giving you the all-important Varnish VCL.

Turpentine is the most feature-rich of the Varnish config, and works great under most conditions. But my one issue with it is that the necessary ESI requests for form_keys can happen many times per page (depending on your templates), and these really add up. I have seen those form_key requests alone overwhelm even a very large web infrastructure, during high traffic events like TV promo and load testing.

My personal favourite is to use the Phoenix PageCache implementation for Varnish, with a few of my own VCL tweaks to sort out User-Agent normalisation, SSL termination, and one or two other bits. With PageCache, the form_keys are generated by an embedded C function, then stored in a header for later re-use. It’s a much more efficient way of dealing with Magento’s form_keys. The free PageCache module for Community Edition doesn’t handle hole-punching for logged-in users as Turpentine can, so everyone with a session bypasses Varnish, but that also makes it simpler to manage; you don’t need to mess with your templates. In my experience it does the best job of handling load spikes and gives you the fewest headaches.

 

Varnish is not a silver bullet

If configured badly, it can cause you no end of problems. Broken sessions, add-to-cart not working, seeing someone else’s shopping cart, and generic 503 errors are very common. On the other hand, a stray Vary: header here, or an unnecessary session_start() there, and the site will seem to work but Varnish probably won’t be caching much.   Varnish can make your site blisteringly fast, but you need some solid experience for a successful implementation.

Do: talk to your dev agency and/or hosting provider for advice and expertise.

Don’t: follow a beginners’ how-to and hope for the best.