Varnish Hosting

Se stai cercando di ottimizzare e velocizzare l’apertura del tuo sito WordPress, WooCommerce o altro, ti sarai sicuramente imbattuto in post e consigli che ti parlavano di installare software o plugin di Cache.

Se sei stato fortunato avrai ascoltato anche qualche professionista parlare di Varnish Cache, piuttosto che di inutili Cache lato plugin o la più banale e meno funzionale Cache server NGINX FastCGI Cache.

Cos’è Varnish Cache?

Ma cos’è di preciso Varnish e perchè è la scelta ottimale se decidi di velocizzare l’esperienza utente del tuo sito Web ?

Varnish Cache è un potente software lato server, scritto nel linguaggio di programmazione C, riconosciuto per le sue prestazioni eccezionali. La sua progettazione e sviluppo sono stati guidati da concetti consolidati e migliori pratiche di sviluppo software, tra cui la gestione dinamica della memoria, l’impiego di thread, l’utilizzo di memoria condivisa e di socket standard POSIX, tra gli altri. Questi raffinati meccanismi sarebbero irrealizzabili con un linguaggio interpretato come PHP.

Contrariamente alle cache PHP menzionate, che entrano in gioco solo dopo l’esecuzione del codice della cache PHP e la generazione di un processo dell’interprete PHP attraverso thread PHP-FPM (Fast Process Manager), Varnish Cache interviene immediatamente. Non coinvolge minimamente PHP né lo spawn di nuovi thread e processi, riducendo significativamente il carico sulla CPU. Questo aspetto si rivela particolarmente vantaggioso quando si gestiscono livelli di traffico web molto elevati, che possono arrivare a migliaia o addirittura decine di migliaia di visitatori simultanei.

In effetti, all’interno di un hosting gestito per WordPress ad alto traffico, l’impiego di Varnish nel nostro stack software ci consente di gestire siti che registrano oltre 45 milioni di visitatori unici al mese, oltre 200 milioni di visualizzazioni di pagine, e picchi di oltre 100.000 utenti al minuto.

Per illustrare questo punto, consideriamo lo screenshot sottostante di Google Analytics relativo a uno dei nostri clienti. Questo sito attrae fino a 85 milioni di visitatori al mese, dimostrando così la scalabilità e la resistenza offerte da Varnish Cache.

Molti visitatori, molti thread PHP ?

Uno degli equivoci più frequenti tra gli amministratori di siti web che gestiscono un alto volume di traffico, con picchi di visitatori che raggiungono le migliaia al minuto, riguarda la gestione dei Listener PHP-FPM. L’errore comune consiste nel tentativo di incrementare il numero di Listener PHP-FPM allo scopo di gestire un maggior numero di connessioni e richieste in ingresso.

Il ragionamento che spesso guida questa decisione può essere schematizzato così:

Se ho 1000 utenti al minuto, piuttosto che impostare i Listener PHP-FPM a 32, posso configurarli a 512. In questo modo, sarò in grado di gestire un maggior numero di richieste.

Questa è una trappola in cui molti cadono, erroneamente convinti che sia sufficiente aumentare il valore del numero di Listener PHP-FPM per gestire un maggior numero di richieste.

Tuttavia, la realtà si rivela molto diversa. Nonostante sia possibile incrementare il numero di Listener PHP-FPM con una semplice modifica del relativo file di configurazione del pool, l’hardware fisico sottostante non può essere adattato altrettanto facilmente. Per esempio, se il tuo sistema dispone di 8 core, impostare 512 thread potrebbe non essere la scelta più saggia. Infatti, questi thread dovranno comunque essere eseguiti sugli 8 core disponibili, comportando l’attivazione del multiplexing del processore e dello scheduling. Questo meccanismo farà sì che vengano eseguiti più processi, ma con tempi di esecuzione ridotti, risultando così più lenti.

Mentre il processore lavora per gestire le operazioni su 512 pool, nuove richieste in ingresso cominceranno ad accumularsi. Queste si aggiungeranno alla coda delle richieste precedenti e, in pochi minuti, la lunghezza di questa coda potrebbe diventare tale da richiedere minuti o addirittura decine di minuti per essere processata. Questo comporta l’insorgere di fastidiosi timeout, come l’errore 502 Gateway Timeout o 502 Bad Gateway.

In conclusione, pur sembrando una soluzione intuitiva, aumentare il numero di Listener PHP-FPM non è sempre la risposta ottimale per gestire un afflusso elevato di utenti. Piuttosto, una corretta comprensione del funzionamento sottostante dell’hardware e del software del sistema può aiutare a trovare strategie più efficaci per gestire l’alta concorrenza di richieste.

PHP fa schifo. MySQL fa schifo. Apache e NGINX fanno schifo. WordPress ? Anche.

Non è raro sentire aspre critiche rivolte a PHP, MySQL, Apache, NGINX e WordPress. Si, l’ho appena affermato e sì, forse sembro un po’ cinico. Tuttavia, la mia intenzione non è di denigrare queste tecnologie, ma piuttosto di sottolineare una realtà concreta: se PHP e MySQL fossero altrettanto rapidi come tecnologie più moderne come Node.js, GoLang, o i database noSQL come Redis.io e MongoDB, l’uso di servizi di cache sarebbe probabilmente superfluo.

Sfortunatamente, il mondo digitale non è così. Ad esempio, molti dei più importanti CMS continuano a basarsi sullo stack PHP + MySQL, rendendo ancora necessario il nostro lavoro e il ricorso a soluzioni come Varnish. E, nonostante le critiche, questo ci fornisce una reale opportunità. Un’opportunità che si traduce in un valore tangibile: la possibilità di ottenere performance più elevate utilizzando hardware più economico.

In ultima analisi, ciò che ne deriva è un duplice vantaggio che ricalca le fondamenta della ricerca operativa: la massimizzazione dei profitti minimizzando i costi. Dunque, invece di svalutare PHP, MySQL, Apache, NGINX e WordPress, potremmo piuttosto riconoscere il loro ruolo nel panorama tecnologico attuale, e lavorare per ottimizzare le loro prestazioni con strumenti adeguati come Varnish, così da trarre il massimo beneficio dalla loro presenza.

Varnish Cache in pratica.

Varnish opera fondamentalmente memorizzando le richieste di tipo GET, come una comune pagina web, all’interno del suo storage. Quest’ultimo può risiedere sia fisicamente su disco, con vantaggi in termini di capacità di storage, sia su RAM, che offre invece vantaggi in termini di velocità di accesso e quindi ridotta latenza.

Immaginiamo che un utente navighi su https://www.sitoesempio.it/azienda dal suo browser. Il funzionamento di Varnish in questa circostanza prevede che il software verifichi inizialmente se la pagina richiesta è già presente nella sua cache. Se la risposta è affermativa, Varnish fornirà prontamente la pagina all’utente. In caso contrario, la richiesta verrà PASSata al backend del webserver, che è tipicamente rappresentato da Apache o NGINX.

Questi server web a loro volta attiveranno l’esecuzione del codice PHP e invieranno le relative query al database MySQL per generare la pagina HTML richiesta. Una volta generata, la pagina viene restituita al webserver, viene memorizzata in cache per utilizzi futuri e infine inviata al browser dell’utente. Così, l’utente potrà finalmente visualizzare la pagina azienda sul sito esempio.

Supponiamo che, alla prima visita, la generazione della pagina richieda un secondo, con un ulteriore ritardo di 50 millisecondi per la consegna al browser del visitatore. Ora, alla seconda visita, dato che la pagina è già stata memorizzata da Varnish, non sarà necessario generare nuovamente la pagina, ma sarà sufficiente inviarla all’utente. Pertanto, invece di impiegare 1 secondo e 50 millisecondi, saranno necessari solamente 50 millisecondi per cercare la pagina nella cache di Varnish e altri 50 millisecondi per consegnarla all’utente. Di conseguenza, il tempo totale di risposta passa da 1,050 millisecondi a 100 millisecondi, con un risparmio del 1500%. Ciò dimostra come Varnish possa avere un impatto significativo sulla velocità di caricamento delle pagine e, di conseguenza, sull’esperienza dell’utente.

E’ ovvio che nella descrizione che ho appena dato è stato tralasciato per comodità di narrazione importanti feature di Varnish, come l’hashing, il fetching, lo stripping dei cookie, dei parametri e via dicendo, funzionalità assolutamente vitali in alcuni casi che fanno di Varnish appunto il fiore all’occhiello dei software di caching.

In questo breve video in inglese della casa madre Varnish-Software potete capire in maniera molto elementare il senso di un software di Cache come Varnish.

Varnish Cache. Grandi poteri, grandi responsabilità.

Proprio come accade per i supereroi nei fumetti e nei film, simbolizzati nella mascotte di Varnish Cache da un coniglio supereroe, grandi poteri comportano grandi responsabilità.

Varnish è indubbiamente uno dei migliori software di caching web disponibili (diciamo pure il migliore), ma, al tempo stesso, è un software “semplice” nel senso che esegue esclusivamente quello che viene configurato per fare. Questo implica che una configurazione accurata e precisa, sia di Varnish stesso che dell’applicazione che si intende utilizzare con esso, è assolutamente fondamentale per ottenere i migliori risultati.

Ci sono diverse domande che ogni sviluppatore, sistemista e utilizzatore di Varnish dovrebbe porsi in fase di configurazione, come ad esempio:

Quanto deve durare la cache ?

La durata della cache è un aspetto cruciale da considerare durante la configurazione di Varnish. Questo perché il tempo di conservazione delle informazioni in cache può variare notevolmente a seconda del tipo di contenuto e della sua frequenza di aggiornamento.

Prendiamo ad esempio la pagina di presentazione istituzionale di un’azienda. Questo tipo di contenuto cambia raramente, forse una o due volte all’anno. Pertanto, per questo tipo di pagina, impostare una durata di cache molto lunga potrebbe essere appropriato, in quanto ciò consentirebbe di servire la pagina molto rapidamente a tutti i visitatori, senza dover ricaricare le informazioni dal server ad ogni richiesta.

D’altra parte, se consideriamo un blog che riporta notizie di calcio in tempo reale durante una partita di Serie A, la situazione cambia drasticamente. In questo scenario, ogni azione significativa della partita, come un’ammonizione, un’espulsione, un calcio di rigore o un gol, potrebbe richiedere un aggiornamento immediato della pagina. In questo caso, impostare una durata di cache troppo lunga potrebbe precludere la possibilità di fornire agli utenti aggiornamenti tempestivi e pertinenti. Pertanto, sarebbe opportuno configurare una durata di cache molto più breve, o addirittura disabilitare completamente la cache durante gli eventi live.

La durata della cache dovrebbe essere attentamente ponderata in base alla natura del contenuto del sito e alla frequenza con cui esso viene aggiornato. Questa considerazione aiuta a bilanciare l’esigenza di fornire contenuti aggiornati con la necessità di mantenere un’alta velocità di risposta del sito.

Come gestisco le pagine AMP con la Cache ?

La gestione delle pagine Accelerated Mobile Pages (AMP) in un ambiente con cache, come quello offerto da Varnish, rappresenta una sfida interessante. Con l’introduzione di AMP, molti aspetti legati al posizionamento sui motori di ricerca, alla SEO in tempo reale e a servizi traffic-driven molto remunerativi come Google News, sono cambiati. Tra le questioni più comuni che emergono in questo contesto vi è proprio la gestione delle pagine AMP.

AMP è un framework sviluppato da Google per migliorare la velocità e l’usabilità dei siti web sui dispositivi mobili. Le pagine AMP sono versioni ottimizzate e semplificate delle pagine web standard, progettate per caricarsi rapidamente sui dispositivi mobili. Questo ha un impatto significativo sulla SEO, dato che Google tende a privilegiare le pagine AMP nei risultati di ricerca effettuati da dispositivi mobili.

Quando si utilizza un sistema di caching come Varnish, è importante considerare come gestire le pagine AMP. In particolare, quando il contenuto di un post viene aggiornato, è fondamentale segnalare a Google che anche la versione AMP del post è stata modificata. Questo perché, se il contenuto AMP non viene aggiornato di conseguenza, si possono creare discrepanze tra la versione standard della pagina e quella AMP, che possono portare a penalizzazioni nei risultati di ricerca di Google.

La strategia ideale per la gestione delle pagine AMP può dipendere da vari fattori, tra cui il tipo di contenuto del sito, la frequenza degli aggiornamenti e la natura del pubblico. Una possibilità potrebbe essere quella di impostare una durata di cache più breve per le pagine AMP, in modo da assicurarsi che vengano aggiornate più frequentemente. Un’altra opzione potrebbe essere quella di utilizzare un sistema di invalidazione della cache, che consente di rimuovere specifiche pagine dalla cache quando il contenuto originale viene aggiornato.

In ogni caso, è fondamentale monitorare attentamente le performance del sito e le metriche di SEO per assicurarsi che la strategia adottata sia efficace e non crei problemi inaspettati.

Come gestiamo i Cookie inutili li lasciamo passare ?

La gestione dei cookie può essere un aspetto particolarmente delicato quando si tratta di caching, in particolare con un software come Varnish. Questo perché la presenza di un cookie potrebbe portare Varnish a considerare una richiesta come “personalizzata” per un utente specifico e, di conseguenza, a non utilizzare la cache.

A volte, si potrebbe imbattere in plugin o codice che setta inutilmente cookie lato server, provocando un’invalidazione della cache anche quando non sarebbe necessario. Questo comportamento può ridurre drasticamente l’efficacia del caching e, di conseguenza, rallentare il sito.

La strategia migliore per affrontare questa situazione può dipendere da vari fattori, tra cui la natura del cookie e le sue potenziali implicazioni per l’esperienza dell’utente e la funzionalità del sito. Se il cookie fosse veramente inutile e non avesse un impatto sulle funzionalità del sito o sull’esperienza dell’utente, potrebbe essere possibile eliminarlo completamente. Questo potrebbe essere fatto modificando il codice che genera il cookie o configurando Varnish per ignorare o rimuovere specifici cookie.

Tuttavia, prima di prendere questa decisione, è importante considerare attentamente le possibili conseguenze. Alcuni cookie, anche se possono sembrare inutili a prima vista, potrebbero avere un ruolo importante per alcune funzionalità del sito o per la conformità a leggi e regolamenti, come quelli relativi alla privacy e alla protezione dei dati.

Pertanto, quando si tratta di gestire i cookie in un contesto di caching, è importante procedere con cautela e preferibilmente con l’assistenza di un esperto di sviluppo web o di un consulente di SEO. È inoltre fondamentale testare attentamente qualsiasi modifica apportata per assicurarsi che non abbia effetti negativi inaspettati sul sito o sull’esperienza dell’utente.

E i file di grandi dimensioni?

Quando si tratta di gestire file di grandi dimensioni in un ambiente con caching, come quello fornito da Varnish, è importante considerare attentamente i pro e i contro. Da un lato, mettere in cache file di grandi dimensioni come immagini ad alta risoluzione, file ISO o archivi ZIP o RAR può sembrare una buona idea per velocizzare il caricamento di questi elementi. Tuttavia, d’altro canto, ci sono alcune considerazioni importanti da tenere a mente.

In primo luogo, mettere in cache file di grandi dimensioni può richiedere una grande quantità di spazio di archiviazione. Questo potrebbe non essere un problema per i siti con una quantità limitata di contenuti di grandi dimensioni, ma per i siti che ospitano un gran numero di tali file, le risorse di storage possono diventare rapidamente un problema. Inoltre, se l’hardware sottostante non è all’altezza del compito, potrebbe verificarsi un rallentamento generale del sistema a causa del carico di gestione di file di grandi dimensioni.

In secondo luogo, ci potrebbe essere un problema con la latenza. Se un utente richiede il download di un file di grandi dimensioni e Varnish deve prima caricare quel file nella sua cache, l’utente potrebbe dover aspettare più a lungo prima che il download inizi. In alcuni casi, potrebbe essere più efficiente far passare la richiesta direttamente al web server, che può iniziare immediatamente a inviare il file all’utente.

Infine, è importante ricordare che i file di grandi dimensioni, in particolare quelli come i file ISO o gli archivi ZIP o RAR, tendono a essere scaricati meno frequentemente rispetto ad altri tipi di contenuti. Di conseguenza, il beneficio di mettere in cache questi file potrebbe non essere così grande come si potrebbe pensare.

Pertanto, quando si tratta di gestire file di grandi dimensioni con Varnish, la strategia migliore potrebbe dipendere dal tipo specifico di sito e dal suo pubblico. Potrebbe essere utile esaminare le statistiche di accesso del sito per determinare quali file vengono scaricati più frequentemente e considerare se ha senso mettere in cache questi file. È inoltre consigliabile monitorare attentamente le performance del sito e fare dei test per determinare l’effetto del caching di file di grandi dimensioni sulle performance complessive del sito.

Come gestisco le pagine utente di un Ecommerce ?

La gestione delle pagine utente in un ecommerce, in particolare in un ambiente che utilizza una soluzione di caching come Varnish, richiede una particolare attenzione. Ci sono alcuni aspetti cruciali da considerare per garantire un’esperienza utente fluida e sicura, rispettando le normative sulla privacy, come il GDPR in Europa.

Il primo aspetto riguarda il carrello. Quando un cliente aggiunge articoli al proprio carrello in un negozio ecommerce come WooCommerce, questi dati sono specifici per quell’utente e non dovrebbero essere condivisi o resi visibili ad altri clienti. Se il carrello venisse erroneamente messo in cache da Varnish, potrebbero sorgere problemi, come mostrare a un utente il carrello di un altro. Per evitare ciò, è necessario configurare Varnish in modo da non mettere in cache le pagine del carrello. In generale, tutte le pagine che contengono dati sensibili e specifici dell’utente non dovrebbero essere messe in cache.

Il secondo aspetto riguarda l’area privata dell’utente, dove possono essere visualizzati i dettagli del suo account, come le informazioni di fatturazione e lo storico degli ordini. Queste pagine sono altamente personalizzate e contengono dati sensibili. Pertanto, come nel caso del carrello, queste pagine non dovrebbero essere messe in cache. È fondamentale garantire che ogni utente possa vedere solo i propri dati e non quelli di altri clienti.

In sintesi, qualsiasi pagina o sezione di un sito ecommerce che contenga informazioni specifiche dell’utente o dati sensibili dovrebbe essere esclusa dalla cache. Questo può richiedere una configurazione attenta di Varnish, così come una comprensione chiara dei requisiti specifici del negozio ecommerce. Questo approccio non solo garantisce una migliore esperienza per l’utente, ma aiuta anche a conformarsi alle normative sulla privacy come il GDPR. E’ importante sottolineare che la configurazione di Varnish dovrebbe essere gestita da professionisti esperti per evitare errori che potrebbero compromettere la sicurezza e la privacy dei dati dell’utente.

Come gestisco le url parametriche di tracciamento come fbclid o utm con Varnish ?

La questione dei parametri di tracciamento come “fbclid” nelle URL, usati frequentemente nelle campagne di marketing online, rappresenta una sfida per l’ottimizzazione della cache con Varnish. Infatti, per ogni URL univoca, Varnish crea una versione separata nella cache. Pertanto, se il parametro “fbclid” cambia per ogni utente che clicca su un link proveniente da Facebook, Varnish tratterà ogni richiesta come unica, bypassando la cache e rallentando la velocità del sito come se non fosse presente alcuna cache.

È possibile, però, gestire in modo elegante e efficace tale situazione, senza compromettere la funzionalità di tracciamento dei parametri come “fbclid” o “UTM” di Google.

Una soluzione può essere quella di configurare Varnish per normalizzare gli URL, rimuovendo o ignorando certi parametri di query string. Ciò può essere fatto attraverso il Varnish Configuration Language (VCL). Nella funzione vcl_recv, è possibile aggiungere un codice che riscrive l’URL, rimuovendo specifici parametri di query. Tuttavia, è importante notare che questa azione non influirà sulla funzionalità di tracciamento, perché i parametri verranno semplicemente rimossi nel momento in cui la richiesta raggiunge Varnish, ma saranno ancora presenti quando la richiesta iniziale viene fatta dal browser dell’utente.

Inoltre, un’altra possibilità potrebbe essere quella di usare una funzione hash in Varnish. In VCL, puoi personalizzare la funzione vcl_hash per ignorare determinati parametri URL quando Varnish decide se una pagina è in cache o meno.

In questo modo, potrai garantire che il tuo sito WooCommerce funzioni alla massima velocità possibile, indipendentemente dalle campagne pubblicitarie che stai gestendo, senza perdere la possibilità di tracciare efficacemente l’origine del traffico verso il tuo sito.

Come utilizzo Varnish con HTTPS ?

L’impiego di Varnish in combinazione con HTTPS può sembrare una sfida complicata, data la presunta incompatibilità tra il sistema di caching di Varnish e il protocollo HTTPS. Infatti, questa supposizione ha portato molti fornitori di servizi web, sia in Italia che a livello internazionale, ad abbandonare Varnish a favore di soluzioni come LiteSpeed Cache. Tuttavia, possiamo affermare con sicurezza che con una configurazione adeguata, Varnish può essere efficacemente utilizzato con HTTPS, e la nostra esperienza ne è la prova vivente.

Varnish di per sé non supporta direttamente HTTPS. Tuttavia, ciò non implica che non possa essere utilizzato in un ambiente che richiede HTTPS. Per aggirare questa limitazione, è possibile utilizzare un reverse proxy come NGINX o Hitch davanti a Varnish. Questi server possono gestire le connessioni HTTPS, decifrarle e poi inoltrare le richieste HTTP a Varnish. In questo modo, si può sfruttare la potenza e le performance di Varnish, pur mantenendo la sicurezza offerta da HTTPS.

Inoltre, implementare Varnish con HTTPS ci ha permesso di sfruttare il protocollo HTTP/2 ed anche HTTP/3 che offre ulteriori vantaggi in termini di performance. HTTP/2 consente la multiplexazione delle richieste, il che significa che possono essere inviate molteplici richieste contemporaneamente sulla stessa connessione, risparmiando tempo e risorse del server.

Scegliere di persistere nell’utilizzo di Varnish, adattandolo all’uso con HTTPS e HTTP2, si è rivelato una decisione vincente per noi. Questa scelta ha portato a un notevole miglioramento in termini di qualità del servizio offerto e ha contribuito a raddoppiare i nostri utili e i nostri fatturati nell’ultimo anno. Il successo che abbiamo riscontrato dimostra che la versatilità e le prestazioni di Varnish possono davvero fare la differenza in un mercato competitivo come quello del web hosting.

Installare Varnish Supercache è diverso da far funzionare Varnish.

Implementare Varnish Supercache non si limita a un’installazione di base: ottenere il massimo da Varnish richiede un processo molto più complesso.

Potresti essere tentato di utilizzare Varnish tramite uno degli hosting che lo offrono come soluzione preconfigurata. Ma è fondamentale comprendere che l’installazione o l’acquisto di Varnish come servizio da un provider di hosting non garantisce la piena funzionalità di questo potente strumento di caching. Varnish richiede un’attenta configurazione sul server, in base alle specifiche esigenze del tuo progetto, così come una precisa impostazione sul backend del tuo sito WordPress, per assicurare il corretto funzionamento di tutte le funzioni di pulizia della cache (purge), delle sitemap, delle pagine AMP, degli Instant Articles, delle pagine utente, della gestione dei cookie e molto altro.

Se la soluzione che ti viene proposta non è personalizzata e non include il supporto di un esperto sistemista che ti assista durante tutte le fasi iniziali – dalla migrazione, alla configurazione, al tuning – allora è probabile che stai per acquistare qualcosa che potrebbe causare seri problemi al tuo sito nel breve e medio termine. Ad esempio, la mancata aggiornamento delle sitemap potrebbe impedire l’indicizzazione su Google dei tuoi nuovi articoli; un malfunzionamento di AMP potrebbe escluderti da Google News; e altri problemi potenzialmente ancora più gravi potrebbero portare, nei casi più estremi, alla disattivazione del tuo sito.

Nel migliore dei casi, potresti ritrovarti con Varnish installato sul tuo server, ma incapace di cachare correttamente i dati, permettendo così a tutte le richieste di passare direttamente al Webserver e, di conseguenza, a PHP e MySQL.

Se il tuo obiettivo è ottimizzare la velocità di un sito WordPress o WooCommerce, gestire elevati picchi di traffico e un gran numero di utenti, noi possiamo aiutarti. Offriamo le migliori soluzioni tecnologiche e sistemistiche al miglior prezzo.

Non esitare a contattarci per scoprire come possiamo supportare il tuo progetto.