Il caching

Modalità di caching

È necessario decidere una politica di caching: l'obiettivo è fare caching di più risposte possibile (per aumentare l'efficienza), ma non farlo mai quando non è permesso (per non rompere funzioni del sito).

Nella modalità predefinita il Web Accelerator segue la normale semantica di HTTP. Questa modalità di solito non è utile, almeno senza una configurazione personalizzata, perché HTTP vieta il caching delle risposte che ricevono o emettono cookie e in genere tutte le richieste ne hanno.

Caching "standard": come evoluzione della precedente, si possono ignorare i cookie per gli oggetti che si presume siano statici, e quindi forzarne il caching: immagini, CSS, Javascript, font, eccetera... Una configurazione di questo tipo funziona senza bisogno di personalizzazioni, però non fa caching delle pagine dinamiche e di conseguenza non permette di avere le migliori prestazioni.

Caching "forzato": si fa caching di tutti gli oggetti tranne quelli esplicitamente esclusi, come per esempio l'area amministrativa del sito o il carrello degli acquisti. Richiede di conoscere in dettaglio il funzionamento del CMS o dello specifico sito, però una configurazione accurata permette un livello di caching ottimale. Il Web Accelerator gestisce automaticamente i casi più comuni grazie a una libreria di moduli di configurazione già pronti per i più diffusi CMS come Wordpress, Joomla e Magento.

È anche possibile usare criteri più complessi dell'URL per escludere qualcosa dal caching: per esempio il Web Accelerator può esaminare i cookie per sapere se una richiesta è stata fatta da un utente autenticato, che quindi deve ricevere una pagina personalizzata.

In più, si possono usare le informazioni contenute nei cookie per partizionare la cache e avere più copie della stessa pagina personalizzate secondo caratteristiche come la lingua, la valuta o anche ciascun utente autenticato.

Rimane inteso che normalmente viene fatto caching solo delle risposte a richieste con i metodi HTTP GET o HEAD.

TTL degli oggetti in cache

Il Web Accelerator tiene in cache gli oggetti per il tempo prescritto dagli header Cache-Control restituiti dal backend, fino a una durata massima (predefinita: 1 giorno).

In mancanza dell'header allora è applicato un TTL predefinito in base all'estensione del file nell'URL: per gli oggetti presunti statici (immagini, CSS, Javascript, font, eccetera...) questo valore è di 1 ora, mentre per le pagine presunte dinamiche (cioè tutto il resto) è di 5 minuti. I redirect 302 e 307 e gli errori 403 e 404 invece sono tenuti in cache per 1 minuto.

Se non è possibile che il backend invii degli header Cache-Control appropriati è comunque possibile configurare sul Web Accelerator delle politiche personalizzate con la massima granularità. Il nostro personale è a disposizione per valutare le impostazioni migliori per ciascun sito.

In caso il backend sia guasto e quindi non sia possibile aggiornare la cache, il Web Accelerator risponde con gli oggetti scaduti fino a un'ora prima.

Si sottolinea quindi che se il backend invia oggetti con header tipo Cache-Control: no-cache ne impedirà il caching: in questo caso, se non è possibile correggerne il funzionamento, si può configurare il Web Accelerator per ignorarli completamente.

Invalidazione della cache

Sono disponibili tre diverse API per invalidare il contenuto della cache:

• Richieste di specifici oggetti con il metodo HTTP PURGE.
• Oggetti corrispondenti a una regular expression richiesta con il metodo HTTP PURGE, aggiungendo un header X-Purge-Method: regex.
• L'API di invalidazione di Drupal, senza bisogno di impostare X-Varnish-Secret.

Le richieste sono accettate solo dall'indirizzo IP del backend, o eventualmente da altri configurati per essere autorizzati. Le richieste PURGE possono essere inviate indifferentemente con HTTP o HTTPS, mentre le richieste BAN devono essere inviate con HTTPS.

Per gestire automaticamente l'invalidazione in Wordpress è possibile installare un plugin che implementi una di queste interfacce, per esempio Proxy Cache Purge.

È disponibile un file di esempio test_purge.php che mostra come invalidare un oggetto con PHP e libcurl.

Disattivazione temporanea del caching

Durante attività di sviluppo che coinvolgano direttamente il sito in produzione è possibile disattivare il caching per la sessione in corso nel browser accedendo a https://<dominio>/seeweb-wa/cache-bypass.

Header informativi

Le risposte di Varnish contengono questi header che permettono di capire da dove arriva l'oggetto:

x-varnish: 5217771 2207419
age: 261

Se X-Varnish contiene due numeri significa che la risposta arriva dalla cache, mentre se ne contiene uno solo significa che arriva dal backend.

L'header Age indica l'età in secondi dell'oggetto restituito.