Tag di cache + Varnish

Varnish Cache è un acceleratore di applicazioni web, noto anche come proxy inverso HTTP con cache. Varnish è utilizzato da migliaia di siti Drupal per aumentare le prestazioni di caricamento delle pagine da 10 a 1000 volte e può essere usato insieme ai tag di cache per semplificare l’invalidazione della cache.

Per un’integrazione di base dei tag di cache, devi fare tre cose per assicurarti che Varnish funzioni correttamente con i tag di cache generati da Drupal:

• Aggiornare il VCL di Varnish affinché gestisca correttamente le richieste BAN.
• Inviare l’header dei tag di cache (ad esempio X-Cache-Tags) con ogni richiesta, contenente la lista separata da spazi di tutti i tag di cache della pagina.
• Inviare una richiesta BAN con i tag di cache appropriati ogni volta che contenuti o configurazioni vengono aggiornati e le pagine con quei tag devono essere invalidate.

Aggiornare il VCL di Varnish

Il pacchetto Symfony FOSHttpCache contiene un’ottima documentazione sulle modifiche VCL necessarie per supportare i tag di cache, ma ecco le modifiche minime al VCL per iniziare (per Varnish 4.x):

All’interno di vcl_recv:

sub vcl_recv {
    ...
    # Consentire solo richieste BAN dagli IP nell’ACL 'purge'.
    if (req.method == "BAN") {
        # Stesso controllo ACL come sopra:
        if (!client.ip ~ purge) {
            return (synth(403, "Not allowed."));
        }

        # Logica per il ban, usando l’header X-Cache-Tags.
        if (req.http.X-Cache-Tags) {
            ban("obj.http.X-Cache-Tags ~ " + req.http.X-Cache-Tags);
        }
        else {
            return (synth(403, "X-Cache-Tags header missing."));
        }

        # Restituire una pagina sintetica per evitare di andare al backend.
        return (synth(200, "Ban added."));
    }
}

All’interno di vcl_backend_response:

sub vcl_backend_response {
    # Impostare header personalizzati compatibili con il ban-lurker.
    set beresp.http.X-Url = bereq.url;
    set beresp.http.X-Host = bereq.http.host;
    ...
}

All’interno di vcl_deliver:

sub vcl_deliver {
    # Rimuovere gli header personalizzati ban-lurker friendly quando si consegna al client.
    unset resp.http.X-Url;
    unset resp.http.X-Host;
    # Commentare queste righe per facilitare il debug dei tag di cache di Drupal in sviluppo.
    unset resp.http.X-Cache-Tags;
    unset resp.http.X-Cache-Contexts;
    ...
}

Assicurati di riavviare Varnish dopo aver applicato le modifiche al VCL!

Inviare l’header di cache

Puoi abilitare uno dei seguenti moduli per fare in modo che Drupal emetta un header HTTP contenente i tag di cache:

Nota: in alcune versioni precedenti alla 8.x-3.0-beta5 il modulo Purge configurava automaticamente l’header Purge-Cache-Tags, ma è stato rimosso perché si è deciso che la responsabilità doveva spettare ai sottomoduli.

Inviare una richiesta BAN quando contenuti o configurazioni cambiano

Usando il modulo Generic HTTP Purger, puoi andare nella pagina di configurazione di Purge (admin/config/development/performance/purge) e aggiungere un HTTP Purger.

Inserisci i dati del tuo server Varnish (hostname, porta, percorso, ecc.) e nella configurazione degli “Header” aggiungi una nuova intestazione con questa configurazione:

• Header: X-Cache-Tags
• Valore: [invalidation:expression]

Una volta salvata questa configurazione di purge e impostato un job cron per processare la coda di purge (drush p-queue-work), Varnish dovrebbe iniziare a invalidare le pagine non appena la coda di purge invierà i comandi BAN!

Alcuni appunti in questa documentazione sono stati adattati dalle seguenti fonti:

• Usare i tag di cache di Drupal 8 con Varnish e Purge
• Aggiungere supporto ai tag di cache nella configurazione predefinita di Varnish in Drupal VM