Skip to main content

Upgrading to Drupal 8 with Varnish, Time to Upgrade your Mental Model as well

I've been using Varnish with my Drupal sites for quite a long while (as a replacement to the Drupal anonymous page cache). I've just started using Drupal 8 and naturally want to use Varnish for those sites as well. If you've been using Varnish with Drupal in the past, you've already wrapped your head around the complexities of front-end anonymous page caching, presumably, and you know that the varnish module was responsible for translating/passing the Drupal page cache-clear requests to Varnish - explicitly from the performance page, but also as a side effect of editing nodes, etc.

But if you've been paying attention to Drupal 8, you'll know that it's much smarter about cache clearing. Rather than relying on explicit calls to clear specific or all cached pages, it uses 'cache tags' which require another layer of abstraction in your brain to understand.

Specifically, the previous mechanism in Drupal 7 and earlier was by design 'conservative' in the sense that many changes to the site caused way more cache clearing than was necessary, just because it had to be sure. So for example, if you edited a node, it would clear the whole site's page cache, because it had no idea which urls that piece of content might show up on (e.g. you might have a 'New content' block on every page that changes with any node edit).

The cache-tags solve this in a 'declarative' way by explicitly declaring dependencies when each page is built by Drupal. So if a page is built and it uses node 5 somewhere in building it, then there's a cache tag attached to the page that says 'node-5'.

With this in place, you can now see that Drupal can be much more clever about clearing caches - e.g. if you edit node 5, you can just clear the pages that have the node-5 cache-tag on it.

Nice idea, and of course, since cache-invalidation is one of those hard things in computing, it's not as easy as it sounds.

But if you're still game, here are a few useful bits I gleaned along the way:

1. The old Drupal varnish module communicated with varnish using the varnish admin port. The New and Better way to talk to varnish is via port 80, using special http methods PURGE and BAN. This means your vcl needs a bit of work (to restrict access, and to do the right thing when receiving these requests, recipe below). You really need to understand the difference between PURGE and BAN - it's the BAN that you're going to use, and the names change in the most recent varnish versions.

2. There is no varnish module for D8 (yet?). There is a 'purge' module and a 'varnish purge' module that together can clear the Varnish page cache correctly. And they use the varnish BAN method, not the PURGE method. Got it?

3. The basic idea is that those cache-tags get attached as http headers to the page, which is then passed to Varnish to deliver. Along the way, Varnish caches the page and then strips off the header before sending it off. So now all those cache tags known by Varnish. The cache tags don't get attached as http headers by default, that needs to be explicitly configured.

4. Now the cache clear request from Drupal gets converted into a BAN request with the appropriate headers, using the purge + varnish_purge modules as per the official recipe or here's a more useful, detailed recipe. But both are confused about the name the cache tag http header, which is currently set to just Cache-Tags (not Purge-Cache-Tags, not X-Cache-Tags).

6. None of that did anything for me and I thought I was still confused (well, yes, I was) until I discovered that the purge module queues up the request but doesn't actually do anything with those requests by default. In the Purge queue, you can actually look in the database of requests, where I saw all my purge requests (yeah, which should get translated to Varnish BAN requests). You can configure how those get triggered, the simple one is as a cron, but that's not going to be super great for many sites. I haven't figured out what the right mechanism might be, but I guess a custom cron every 5 minutes that only does this one cron task would be okay.

So, a lot of new things to learn.

Popular posts from this blog

What to do in the age of Trump?

Well, that's the question of the day. If you're part of an organization that does advocacy work, rather than waiting to see what happens first, might as well get yourself ready, even if the details are sketchy still. Here's one opportunity that's ready for you now, message courtesy of Steve Anderson of OpenMedia.

OpenMedia, David Suzuki Foundation, SumOfUs and a range of other organizations are supporting a new shared set of civic engagement tools.

Vancity Community Foundation is providing some support to subsidize some of the cost of the tools to select values-aligned organizations that sign up before February 28th.

Interested? You can learn more or book a demo from here:

Here's some live examples of the tools you can take a look at:

1. Click to Call:

Check out this video of David Suzuki's d…

Me and varnish win against a DDOS attack.

This past month one of my servers experienced her first DDOS - a distributed denial of service attack. A denial of service attack (or DOS) just means an attempt to shut down an internet-based service by overwhelming it with requests. A simple DOS attack is usually relatively easy to deal with using the standard linux firewall called iptables.  The way iptables works is by filtering the traffic based on the incoming request source (i.e., the IP of the attacking machine). The attacking machine's IP can be added into your custom ip tables 'blacklist' to block all traffic from it, and it's quite scalable so the only thing that can be overwhelmed is your actual internet connection, which is hard to do.

The reason a distributed DOS is harder is because the attack is distributed from multiple machines. I first noticed an increase in my traffic about a day after it had started - it wasn't slowing down my machine, but it did show up as a spike in traffic. I quickly saw that…

CiviCRM's invoice_id field and why you should love the hash

I've been banging my head against a distracted cabal of developers who seem to think that a particular CiviCRM core design, which I'm invested in via my contributed code, is bad, and that it's okay to break it.

This post is my attempt to explain why it was a good idea in the first place.

The design in question is the use of a hash function to populate a field called 'invoice_id' in CiviCRM's contribution table. The complaint was that this string is illegible to humans, and not necessary. So a few years ago some code was added to core, that ignores the current value of invoice_id and will overwrite it, when a human-readable invoice is generated.

The complaint about human-readability of course is valid, and the label on the field is misleading, but the solution is terrible for several reasons I've already written about.

In this post, I'd like to explain why the use of the hash value in the invoice_id field is actually a brilliant idea and should be embrac…