Introduction
This article is for customers as a part of the beta program for Drupal 8 cache tags invalidation and Acquia Purge. We are excited to bring these site performance enhancing capabilities to the Acquia Cloud platform and to your site. We appreciate your participation.
All you need are the Purge and Acquia Purge suite of modules installed on your Acquia Cloud website.
Please contact Acquia Support to let us know you're willing to participate in the Public Beta and for us to help you be successful. Need help with Acquia Support tickets? Read more here.
Why cache tags invalidation?
Drupal 8 features cache tags invalidation as a major performance enhancement for every type of site, especially those with highly dynamic content. It is designed to allow very selective invalidation of cached content, allowing sites to refresh only a subset of elements on the page. This, in turn, reduces backend load and decreases page load times.
Why does this program exist?
Cache invalidation by tags allows sites to virtually cache never-changing content forever. This results in a drastic workload shift from web servers to load balancers. The purpose of this program is to understand how much this affects overall hardware usage. This means we want to monitor hardware and also filter out any potential technical issues before we can safely announce cache tags invalidation support to all Acquia customers running Drupal 8 sites.
How is Acquia supporting cache tags invalidation?
Drupal 8 tags all content pieces it renders with a descriptive tag, for instance "node:123" for a content item. When Drupal renders that node onto a page or as part of a page (for instance as a teaser or inside a view), it collects all these tags together and allows the Purge and Acquia Purge modules to emit all the tags in a HTTP response header. Put differently, every page Drupal now sends to Varnish will contain a technical overview of what is shown on the page to the user. This includes not just content nodes, but everything else that is visible, from blocks to the theme that is in use.
Your Acquia Cloud load balancers are powered by Varnish, which is now configured to store these special headers and to remove them when the page is delivered to your browser or CDN. However, this is just half of the machinery at play here. When you or a colleague logs in to Drupal and edits node 123, Drupal will gather the tags that now changed and will immediately remove all the URLs from its own internal page cache. The Purge module also receives these tags from Drupal and will now queue them to have them removed from your Varnish-powered load balancers as soon as possible. The Acquia Purge module provides the plugin to the Purge module, which will actually send the right commands to Varnish to make sure all URLs are also removed from your load balancers.
Because tags cover everything rendered by Drupal, you can now put the TTL time of your site to extremely high values (e.g. a year). This instructs Varnish and CDNs to cache all pages virtually indefinitely and Purge will now proactively remove items when they actually changed. The major breakthrough is that web servers are freed up for only backend and authenticated traffic and push as much work as possible into Varnish. This massively improves your baseline performance, increases DDoS resilience and might even reduce your hardware bill.
Why do you need a production site?
We need real-life data to confirm cache tags invalidation works as anticipated on the Acquia platform. It is only in the context of a production site with a real caching strategy that we will be able to analyze data and confirm customers are seeing the maximum caching benefit. We also want to provide an opportunity for several customers who have a real business need and desire for this functionality to participate in the release of the feature and see early results.
Why do you need a one month TTL?
The reason we are enforcing a minimum of a month during the testing program is that we need to operate on the assumption that Varnish is caching everything for as long as our measuring takes place. The module will stop working if you have a lower setting, but anything longer than a month is allowed.
After the program, you'll be able to change the TTL to any other value, though we'll still recommend you set it to a year.
How do I install and configure it?
WARNING - The steps below include Purge Drush commands. Purge Drush commands are not yet compatible with Drush 9.
1) Add Purge and Acquia Purge modules to your codebase. You should always use the latest (non-dev) available release. Enable the following modules:
purge
purge_ui
purge_drush
purge_queuer_coretags
purge_processor_cron
purge_processor_lateruntime
acquia_purge
2) Increase your TTL/max-age to 1 month at a minimum. Navigate to /admin/config/development/performance and select 1 month in the Page cache maximum agedropdown, in the Caching section.
Alternatively, you can use Drush:
$ drush @site.env config-set -y system.performance cache.page.max_age 2764800
3) Navigate to /admin/config/development/performance/purge and click on the Add purger button in the Cache invalidation section (sometimes it might require that you rebuild caches for the Add purger button to show up). A pop-up will ask which purger you wish to add. Acquia Cloud will be selected by default. Simply hit Add. Once the purger has successfully been added, a green tick appears in the TAG column.
Alternatively, you can use Drush to add the purger:
$ drush p-purger-add --if-not-exists acquia_purge
The purger has been created!
4) To confirm your setup is complete, visit /admin/config/development/performance/purge, or run drush purge-diagnostics. If all checks return OK, then it means you're all set.
$ drush @site.env p-diagnostics
Title Recommendation Severity
Load Balancers 10.11.12.13, 10.14.15.16 OK
Acquia Cloud site (dev) OK
Processors Drush p-invalidate, Drush p-queue-work, Cron OK
processor, Late runtime processor, Purge block(s)
You have multiple processors working the queue.
Page cache installed OK
Tests if the page_cache module is installed.
Queuers Drush p-queue-add, Core tags queuer, Purge OK
block(s)
You have multiple queuers populating the queue.
Capacity 100 OK
Your system can invalidate 100 items when you are
processing through webserver-initiated requests.
Under ideal conditions - for example via Drush -
the capacity would be 100.
Purgers Acquia Cloud OK
Purger configured.
Page cache max age 1 month OK
Consider increasing your TTL to over a year, the
better your site will perform!
How to invalidate tags with your CDN?
First, make sure your CDN provider supports tag-based invalidation. It's a pretty innovative technology and not all vendors are compatible just yet.
Cloudflare
To invalidate tags with Cloudflare in front, you'll have to use the Cloudflare module. It's now a purger to the Purge API, and invalidation should work transparently as with the Acquia Purge module. Please keep in mind the following caveats:
- Purging by tags is available for Enterprise only
- Cloudflare has a daily upstream API rate limit (2,000 calls x 30 tags)
- Because of that API rate limit, and depending upon the number of requests for invalidation your site makes, cache invalidation might "stop" multiple times a day, letting Purge keep things in its queue until CloudFlare's API limit for the day has expired.
- To work around this issue, you could ask Cloudflare to increase the API limit, but please keep in mind the Drupal Cloudflare module depends on the cloudflarephpsdk SDK and API call limits are hardcoded there so even if the limits were increased at Cloudflare, you would be limited by the SDK regardless.
- We are working with the SDK maintainer to remove this limitation
- As an interim solution, we advise to default to a short TTL at the edge while Cloudflare is evaluating higher defaults for Drupal 8 sites. For this, you can create a Cloudflare Page Rule; see their article on the Edge Cache TTL Settings.
Akamai
Unfortunately, Akamai doesn't yet support tag-based invalidation. This can cause issues and even bring your site down when sending too many URLs for invalidation at once. Please carefully evaluate your caching strategy with this limitation in mind.
To still benefit from fresh content with Akamai in front, you can:
- Set a low TTL on the edge (e.g. 5 min) - Recommended
- Leverage the URLs queuer module to trigger legacy URL or path based invalidation - Not recommended! Read why .
Akamai is in the process of testing tag-based invalidation and should be able to support it sometimes in (but no earlier than) Q1 2018. Please get in touch with them to know more about their readiness status.
Note: Acquia is not in a position to influence Akamai's roadmap. ETA is subject to change.
How do you take advantage of cache tags invalidation?
Cache tags invalidation works like magic. There’s no cache you need to rebuild yourself, nor any additional complex set-up or cache invalidation strategy you need to implement. This is why a high TTL is actually a good thing with Drupal 8. Your newly configured purger will take care of automatically invalidating the obsoleted cache tags on your site.
Understanding the flow
