Varnish voor Drupal

Varnish is een cache die voor de site geplaatst wordt en ook beschikbaar voor Drupal sites bij Byte als je een Performance, Optimize of MCU pakket hebt voor je website. In dit artikel leggen we uit hoe je aan de slag kunt gaan met Varnish voor jouw Drupal site!

Snelle instructies

  1. Download de speciale Drupal Varnish module voor Byte
  2. Pak de bestanden uit naar sites/all/modules/contrib
  3. Ga naar de backend van je Drupal site en dan naar Administer > Modules
  4. Activeer. Klaar! Problemen? Lees verder.

Modules

Het clusterplatform van Byte is geschikt voor Drupal. Varnish neemt de instellingen over zoals die op zijn gegeven op de performance pagina van Drupal: http:// <url van je site>/admin/config/development/performance De pagina’s worden bij het opvragen in de cache opgenomen en gedurende de tijd die is ingesteld voor volgende verzoeken van uit de cache geserveerd aan de gebruiker. In de praktijk wil je echter soms dat een pagina niet pas na het verstrijken van de levensduur in de cache opnieuw wordt opgehaald, maar actief een nieuwe versie aanbieden. Bijvoorbeeld zodra er nieuwe content verschijnt (of blokken of views vernieuwd zijn). Dit kan door de betreffende data in de cache te ‘purgen’. Bij het eerst volgende verzoek wordt de data niet uit Varnish maar op de normale manier opgehaald van het cluster en vervolgens opnieuw in de cache opgenomen. Er zijn voor Drupal diverse modules beschikbaar die het purgen van Varnish caches kunnen verzorgen. De eerste module waar je bij uitkomt heet niet verrassend Varnish. Deze module communiceert via een aparte socket direct met Varnish, maar dit is bij Byte vanwege de cluster-setup niet mogelijk. In de setup bij Byte moet via http met Varnish worden gecommuniceerd. Deze module kan je dus niet gebruiken. De bestaande module Purge lijkt vervolgens een goed alternatief, maar ook deze module werkt niet lekker samen met de omgeving bij Byte, omdat:

  1. Purge requests sturen over https niet lukt
  2. Het standaard niet mogelijk is om gelijktijdig een pagina te purgen van zowel de https en http cache. Er is daarom een variant van deze module ontwikkeld, die genoemde problemen ondervangt. Deze module heet Byte Purge en is te downloaden via https://www.drupal.org/sandbox/bytebv/2424993

Stappenplan

1. Code clonen Clone de module naar de map byte_purge met:

git clone --branch 7.x-1.x https://git.drupal.org/sandbox/bytebv/2424993.git cluster_varnish_for_drupal

2. Installatie en configuratie Je installeert de module op de gebruikelijke manier voor je site. De configuratie van Varnish doe je via http:// <url van je site>/admin/config/development/performance> Dit is de normale Drupal performance pagina. De Byte Purge module is zo gemaakt dat de bestaande cache-instellingen transparant worden doorgegeven aan de browser. Om aan te kunnen geven hoelang de cache in Varnish geldig is, is aan deze pagina een dropdown ‘Varnish expiration’ toegevoegd.
3. Purgen configureren Zoals gezegd, is de Byte Purge module er omdat Drupal zo een manier heeft om aan Varnish door te geven dat er gepurged moet worden. Er moet echter ook nog bepaald worden wát er gepurged moet worden. Dit is eenvoudig in te stellen via de bestaande module Expire. Ook kan je met de module Rules eigen regels maken, om nog meer op maat de cache te purgen, bijvoorbeeld periodiek.

Tweaks

Nog meer speed

In bepaalde gevallen (zie toelichting bij Achtergrond) worden pagina’s voor gebruikers die een cookie hebben voor iedere gebruiker apart gecached. Om de efficiëntie van de caching te verhogen kan dan het wenselijk zijn om de instelling ‘omit_vary_cookie’ te gebruiken. Hiermee wordt aangegeven dat dezelfde cache gebruikt kan worden voor al deze gebruikers. Dit is te activeren door in settings.php op nemen:

$conf['omit_vary_cookie']=TRUE;

Nota bene: zodra een gebruiker inlogt en dus een sessie cookie krijgt, wordt de Varnish cache sowieso overgeslagen.

Alle cache clearen

De module Byte Purge voorziet met opzet niet in het purgen van de volledige cache als je in Drupal op de gebruikelijke manier kiest voor ‘Alle caches legen’. Bij een site waar Varnish in gebruik is, is het niet ondenkbaar dat dit behoorlijke gevolgen voor de performance kan hebben.Wil je niettemin toch in één keer de Varnish cache in zijn geheel legen, dan kan dit door een Drupal rule aan deze actie te koppelen en dan /* op te geven voor de urls die gepurged moeten worden. Overigens komt deze functionaliteit ook via het Byte servicepaneel beschikbaar.

Achtergrond

Vary

Met de “Vary” response header kan je er voor zorgen dat reverse proxies (zoals Varnish) meerdere variaties van een pagina bijhouden. Standaard staat in de Vary header “Accept-Encoding”. Dit is noodzakelijk, want de browser stuurt dan mee welke encodings worden ondersteund. Gevolg is dat Varnish nu voor elke type encoding een aparte cache bijhoudt. Dit is gewenst, want je wilt niet dat de browser een response krijgt met een encoding die hij niet ondersteunt. Dit werkt net zo als “Cookie” in de Vary header zit; Varnish gaat dan voor elke mogelijke inhoud van een Cookie een aparte cache bijhouden. Met als gevolg dat hierdoor de cache hit rate omlaag gaat, terwijl dit eigenlijk niet nodig is. Met ‘omit_vary_cookie’ in settings.php voorkom je dan dit gedrag.

Browser caching

Je vraagt je wellicht af, waarom er in afwijking van de bestaande Purge module, een aparte instelling is voor de Varnish expiration bij de Byte Purge module. Normaal worden pagina’s die voor een bepaalde tijd gecached mogen worden in feite in je webbrowser gecached. Varnish geeft standaard de cache control headers door aan de browser, wat betekent dat als je geen maatregelen neemt, pagina’s dus ook in je browser gecached kunnen worden. Soms is dit ongewenst, bijvoorbeeld in de situatie waarbij als je inlogt, er nog niet-ingelogde varianten van pagina’s in je browserchache zitten. Je zou de caching in Drupal uit kunnen zetten, maar dan stuurt Drupal een cache-control: no-cache header mee. Dit draait er vervolgens op uit dat er niets meer in Varnish wordt gecached. Dat is dus ook niet de bedoeling. De oplossing om tóch controle te blijven houden over de cache-instellingen die aan de browser worden doorgegeven, is dus gevonden in een aparte instelling voor Varnish. Technisch is dit opgelost door Varnish in te stellen via de parameter ’s-maxage’, die prioriteit heeft boven de standaard max-age parameter.

Known issue

In theorie zou je de browser cache op 0 kunnen zetten en Varnish op 1 dag. Maar helaas dit werkt niet (altijd) zoals verwacht. Dit kan je oplossen door de cache-control header via .htaccess te overschijven door ‘no-cache’ door te geven. Als je hier dan handmatig een s-maxage aan toevoegt dan zal Varnish deze waarde nemen voor de cache.

Tot slot

Voor meer informatie over Varnish en achtergrondinformatie zie: Labtest: 6 keer snellere laadtijden met Varnish

Dit artikel is mogelijk gemaakt door de hulp van onze partner Mediagrip!


3