Varnish e Cache Control, come padroneggiare correttamente la durata della Cache

Introduzione

Varnish Cache è un popolare proxy HTTP inverso e acceleratore HTTP. Si trova di fronte ai nostri servizi web/applicativi e utilizza una gamma di tecniche di memorizzazione nella cache, prelettura e compressione per ridurre il carico sui servizi di back-end upstream e fornire tempi di risposta client migliori ai nostri clienti.

Oltre a migliorare le prestazioni, una caratteristica forse meno nota di Varnish è che può essere configurato per proteggere i client da errori e interruzioni a monte. Se un servizio upstream è temporaneamente non disponibile o inizia a restituire errori, Varnish è in grado di eseguire il fallback per fornire risposte obsolete dalla sua cache, a condizione che il periodo di grazia degli oggetti memorizzati nella cache non sia scaduto.

Possiamo ormai dire senza farne segreto che Varnish Cache sia alla base della nostra infrastruttura e dei nostri servizi di Hosting Performance.

Cache Control

Il ruolo cache-controldell’intestazione è istruire le cache a valle (browser e cache proxy come Varnish) su come memorizzare nella cache le risposte. Il valore di s-maxageconsente a Varnish di conoscere il numero di secondi per i quali la risposta può essere memorizzata nella cache, altrimenti noto come tempo di vita (TTL). Il valore di max-ageverrà utilizzato dalle cache del browser (e anche dalle cache proxy nel caso s-maxagenon specificato). Interno a Varnish il valore viene utilizzato per impostare la beresp.ttlvariabile.

Il stale-while-revalidatevalore informa la cache per quanto tempo è accettabile riutilizzare una risposta obsoleta. Nell’esempio precedente, la risposta diventerà obsoleta dopo 10 m (600 s), quindi la cache può riutilizzarla per qualsiasi richiesta effettuata entro i 2 giorni successivi (172800 s). Questo è anche noto come periodo di grazia, interno a Varnish il valore viene utilizzato per impostare la beresp.gracevariabile. La prima risposta recuperata durante il periodo di grace attiverà una richiesta di recupero in background asincrona, rendendo nuovamente aggiornato l’oggetto memorizzato nella cache, senza trasferire il costo di latenza della riconvalida al client.

Inoltre, se il servizio di back-end non è disponibile o risponde lentamente, i client saranno protetti da tali risposte fino alla scadenza del periodo di tolleranza, si spera fornendo al servizio un tempo adeguato al ripristino, o agli ingegneri un tempo adeguato a risolvere un problema, prima che ciò impedisca negativamente sull’esperienza del cliente. Non bisogna trascurare il fatto che si tratta di un compromesso: sebbene fornisca risposte più rapide e maggiore resilienza, aumenta anche le possibilità di fornire risposte obsolete o addirittura per questo motivo errate.

L’impostazione di una stale-while-revalidatedurata elevata è un giudizio e potrebbe non essere appropriato per le risposte contenenti dati di rendering lato server altamente dinamici, in cui l’aggiornamento è fondamentale. Abbiamo cercato di massimizzare l’uso della funzione sulle risposte contenenti dati relativamente statici, come i nostri contenuti editoriali e le pagine di destinazione delle categorie.

Configurazione di Varnish

Per impostazione predefinita, Varnish ripiegherà per fornire una risposta obsoleta durante il periodo di tolleranza se non è possibile connettersi al servizio di backend o se la richiesta scade. Il comportamento può essere esteso agli errori 5xx con il seguente codice insub vcl_backend_response

sub vcl_backend_response {    if (beresp.status >= 500 && bereq.is_bgfetch) { 
        return (abbandono); 
    }    .... 
}

beresp.statuscontiene il codice di stato restituito dal servizio di backend, bereq.is_bgfetchsarà vero se la richiesta di backend è stata inviata in modo asincrono dopo che il client ha ricevuto una risposta memorizzata nella cache e return (abandon)indica a Varnish di abbandonare la richiesta e non fare nulla.

In conclusione

Una risposta memorizzata nella cache non aggiornata, se disponibile, nella maggior parte dei casi fornirà un’esperienza cliente migliore rispetto a una pagina di errore. Laddove il contenuto di rendering lato server è sufficientemente statico da consentire una stale-while-revalidatedurata elevata, ricorrere alla cache può essere uno strumento utile da avere per aumentarne la resilienza.