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 ?

Perchè dovresti preferirlo a cache php applicative come Fastest cache, Batcache, Wp Rocket, W3 Total Cache e simili ?

Varnish Cache è un software lato server scritto in linguaggio C e dunque davvero molto performante. Esso è stato ideato e sviluppato tenendo a mente i migliori concetti e best practices per lo sviluppo software come la gestione dinamica della memoria, l’utilizzo di thread, memoria condivisa, socket standard POSIX e molte altre accortezze che sarebbero di fatto IMPOSSIBILI con un linguaggio interpretato come PHP.

Mentre le cache PHP sopra menzionate si attivano dopo aver eseguito il codice della cache PHP e dunque aver spawnato (generato) un processo dell’interprete PHP tramite thread PHP-FPM (Fast Process Manager), una cache Varnish risponde per primo nell’immediato senza tirare minimamente in ballo PHP e lo spawn di nuovi thread e processi, e dunque risparmiando moltissima CPU per queste operazioni che possono essere davvero molto pesanti di fronte ad un traffico Web molto elevato di migliaia o decine di migliaia di utenti visitatori.

Diciamo che in qualità di hosting managed ad alto traffico WordPress, Varnish all’interno del nostro stack software ci permette di reggere siti con oltre 45 milioni di visitatori unici al mese, oltre 200 milioni di pagine viste, e picchi di oltre 100 mila utenti al minuto.

Nello screenshot di Google Analytics di seguito ad esempio, un nostro cliente che fa 85 milioni di visitatori al mese.

 

Molti visitatori, molti thread PHP ?

Uno degli errori più comuni di chi ha picchi di visitatori nell’ordine delle migliaia al minuto è quello di aumentare il numero di Listener PHP-FPM al fine di servire più connessioni e richieste in ingresso.

La logica è pressapoco la seguente : “Ho 1000 utenti al minuto ? Invece di impostare i listener PHP-FPM a 32 li imposto a 512 e dunque riuscirò a servire più richieste”.

Questo è l’errore che hanno (e abbiamo) fatto tutti, pensando che basta alzare questo valore per poter riuscire a servire più richieste.

Peccato che la realtà è ben diversa e per quanto un numero si possa alzare semplicemente cambiandolo dal rispettivo file di configurazione del pool php-fpm, l’hardware fisico sottostante non si può cambiare con la stessa facilità, per cui se ti ritrovi 8 core, non ha gran senso impostare 512 thread, dato che questi thread dovranno girare comunque sempre sugli 8 core, e pertanto entrerà in gioco il multiplexing del processore e lo scheduling che di fatto farà in modo di eseguire più processi con tempi di esecuzione più bassi e dunque molto più lenti. Nel frattempo che il processore terminerà di eseguire le operazioni su 512 pool, ci saranno nuove richieste in ingresso da processare che si accoderanno alle precedenti e così facendo nel giro di qualche minuto si genererà una coda così lunga che impiegherebbe minuti o decine di minuti per essere eseguita e dunque generando fastidiosi timeout come il famosissimo 502 Gateway Timeout o 502 Bad Gateway.

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

E si, l’ho detto. Sono una brutta persona. Ma sono anche piuttosto realista, dato che se PHP e MySQL fossero veloci come Node.js, GoLang, e DB noSQL come Redis.io o MongoDB, probabilmente non dovremmo avere a che fare con servizi di cache dato che sarebbero superflui.

Purtroppo così non è, e il fatto che ad esempio i maggiori CMS utilizzino lo stack PHP + MySQL fa si che il nostro lavoro (e software come Varnish) abbia ancora un senso e sopratutto un valore. Un valore che si può tradurre banalmente in maggiori performance usando hardware più economico. Alla fine insomma, un doppio vantaggio come insegna la ricerca operativa, massimizzare i profitti minimizzando i costi.

Varnish Cache in pratica.

Praticamente Varnish memorizza richieste di tipo GET (come una normalissima pagina Web) e la memorizza nel suo storage (che può essere sia fisicamente su disco che su RAM) con i relativi pro e contro in termini di latenza e dunque velocità.

Se l’utente digita https://www.sitoesempio.it/azienda sul suo browser, Varnish controllerà se ha già la pagina nella cache e se si la fornirà, altrimenti PASSerà la richiesta al backend del webserver (normalmente Apache o NGINX) che a loro volta chiederanno l’esecuzione di PHP e le relative query al DB MySQL per generare la pagina HTML che verrà restituita al webserver, memorizzata per uso futuro e infine restituite al browser dell’utente che finalmente potrà leggere la storia dell’azienda del sitoesempio.it

Se alla prima visita ad esempio, la generazione della pagina impiega 1 secondo, e 50 millisecondi per la consegna al browser del visitatore, alla seconda visita (essendo la pagina già memorizzata da Varnish) la pagina non dovrà essere generata ma solo inviata all’utente, pertanto invece di impiegare 1 secondo e 5 millisendi, impiegherà 50 millisecondi per la ricerca nella cache Varnish, 50 millisecondi per la consegna della pagina passando dunque da 1 secondo e 50 millisecondi a 100 millisecondi della seconda visita. Un risparmio del 1500% insomma.

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à.

Come per tutti i supereroi che si rispettino (la mascotte di Varnish Cache è proprio un coniglio supereroe) a grandi poteri corrispondono grandi responsabilità. 

Se è vero infatti che Varnish sia il miglior software di Caching Web, è altrettanto vero che fondamentalmente è un software stupido che fa solo quello che gli viene impartito di fare tramite una puntuale e minuziosa configurazione sia di Varnish sia dell’applicativo che deve girarci sopra.

Tra le domande importanti che ogni sviluppatore, sistemista e utilizzatore di Varnish dovrebbe farsi ci sono ad esempio ?

 

Quanto deve durare la cache ?

Perchè se è vero che la pagina di presentazione istituzionale di un’azienda potrà subire 1 o 2 variazioni all’anno, magari la gestione di un blog calcistico che fa cronaca in tempo reale di una partita di calcio di serie A, avrà bisogno di aggiornare la pagina della diretta ad ogni azione saliente del match di calcio, sia esso un’ammonizione, che un’espulsione, un calcio di rigore, o un gol segnato con l’esplosione dello stadio per l’entusiasmo.

Come gestisco le pagine AMP con la Cache ?

Sappiamo che con l’avvento di AMP, sono cambiati molti fattori in gioco inerenti il posizionamento, la seo real time, e servizi molto remunerativi in termini di traffico come Google News. Una delle problematiche più frequenti riguarda proprio al gestione delle pagine AMP, ovvero far presente ai servizi di Google che il contenuto del post è stato aggiornato e dunque anche il rispettivo contenuto AMP è stato modificato.

Come gestiamo i Cookie inutili li lasciamo passare ?

Se un plugin stupido ed inutile mi setta un cookie lato server, questo andrà ad invalidare la cache. Come gestiamo dunque questo aspetto ? Lo lasciamo passare, lo eliminiamo ? Con quali accortezze ?

E i file di grandi dimensioni ?

Ha senso per un sito con molti contenuti statici (immagini, iso, file archivio tipo zip, rar ad esempio) mettere in cache questi contenuti che sono già belli e pronti per conto loro ? Ha senso leggere un file iso da 4 giga magari, metterlo in cache e poi ripescarlo dalla cache rimandandolo al browser ? O forse è più sensato passare la richiesta direttamente al webserver che inizierà immediatamente con lo stream del file senza inutili attese e caching ?

Come gestisco le pagine utente di un Ecommerce ?

Cosa succede se ad esempio su un sito WooCommerce con Varnish pur avendo un catalogo in comune anche il carrello viene cachato ? Vedrò i miei prodotti o quelli di altri utenti ? E se l’utente è loggato con le sue credenziali nella sua area privata ? Vedrà i suoi dati e le sue fatture o quelli di altri clienti ? Questo aspetto oggi più che mai alla luce delle nuove regole europee sulla privacy (GDPR) è importantissimo.

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

Cosa succede se ad esempio su un sito WooCommerce con Varnish decidiamo di usare una campagna di Facebook advertising dove il link uscente dalla piattaforma Facebook, appende alla url un parametro del tipo fbclid=stringarandom per ogni utente ? Come evitare che questa stringa possa bypassarmi la cache Varnish, rendendo il sito lento come se non ci fosse alcuna cache sopra ? Come gestire elegantemente questa situazione senza mettere meno la funzionalità tracciante del parametro fbclid (o altri parametri di tracciamento come UTM di Google) ?

Come utilizzo Varnish con HTTPS ?

Può sembrar stupido, ma con il passaggio “obbligato” voluto da Google da HTTP ad HTTPS, abbiamo visto molti fornitori italiani e internazionali abbandonare Varnish come sistema di Caching in quanto incompatibile con il protocollo HTTPS per convertirsi a LiteSpeed Cache. Sicuramente ne abbiamo tratto un gran beneficio continuando ad utilizzare il ben più versatile e performante Varnish, adattandolo all’utilizzo con HTTPS e HTTP2. Questa scelta ci ha permesso di elevarci come qualità e raddoppiare nell’ultimo anno sia gli utili che i fatturati.

Installare Varnish Supercache è diverso da far funzionare Varnish.

Se arrivato a questo punto hai pensato di installare Varnish o farlo su uno di quei pochi hosting che sponsorizzano Varnish tra le loro soluzioni preconfigurate, devi sapere che Varnish non basta installarlo o comprarlo come servizio da qualche venditore di hosting, ma va installato, configurato lato server in base alle specifiche del progetto e configurato sul progetto WordPress ad esempio (nel backend) affinchè funzionino correttamente tutte le funzioni di pulizia cache (purge), delle sitemap, delle pagine AMP, degli instant article, delle pagine utente, della gestione dei cookie, e molto molto altro.

Se non ti stanno proponendo una soluzione sartoriale su misura, con tanto di sistemista senior che ti seguirà in tutta la fase iniziale a partire dalla migrazione, alla configurazione al tuning, molto probabilmente stai comprando qualcosa che nel breve e medio termine andrà a creare grossi danni al tuo sito. Non aggiornando le sitemap ad esempio rischierai di non vedere indicizzazione su Google per i tuoi nuovi articoli, un malfunzionamento di AMP ti butterà fuori da Google News, e problemi simili anche più gravi che hanno visto in alcuni casi letteralmente la morte del sito di chi ha provato a fare da soli.

Nella migliore delle ipotesi ti troverai con un Varnish installato che non cacha nulla e lascia passare tutte le richieste al Webserver e seguentemente PHP e MySQL.

Se la tua esigenza è quella di velocizzare un sito WordPress o WooCommerce, gestire picchi di traffico elevati e molti utenti contattaci pure, abbiamo per te le migliori soluzioni tecnologiche, sistemistiche al miglior prezzo.

Contattaci subito.