Indice dei contenuti dell'articolo:
Introduzione: una cache che “non funziona” solo in apparenza
La richiesta di consulenza è arrivata come spesso accade nel nostro settore: un confronto tra sistemisti, sollecitato da un problema che sembrava ormai conclamato.
Un e-commerce WooCommerce, traffico crescente, prestazioni altalenanti e una convinzione ormai radicata: Varnish non cacha.
Chi gestiva l’infrastruttura aveva già fatto diverse verifiche superficiali. Gli header HTTP mostravano cache MISS frequenti, l’header Age restava costantemente a zero e l’impressione generale era che il reverse proxy non stesse apportando alcun beneficio reale. Da qui l’idea che il problema fosse lo strumento stesso.
Il nostro intervento non nasceva per “smentire” qualcuno, ma per fare ciò che riteniamo sempre indispensabile: osservare il sistema nel suo complesso, partendo dai dati e non dalle sensazioni.
Lo stack reale: architettura corretta, aspettative sbagliate
Uno dei primi elementi che abbiamo chiarito è stato lo stack effettivamente in uso, perché anche su questo punto c’era una certa confusione.
L’architettura era la seguente:
- NGINX come terminatore HTTPS, esposto pubblicamente
- NGINX in reverse proxy verso Varnish
- Varnish come cache HTTP
- Varnish in reverse proxy verso NGINX
- NGINX collegato a PHP-FPM
- MariaDB come database
Si tratta di uno stack assolutamente classico, che utilizziamo anche noi in moltissimi contesti di produzione. Nulla di sperimentale, nulla di intrinsecamente sbagliato.
Proprio per questo, l’idea che “Varnish non funzioni” in uno scenario del genere meritava un’analisi più approfondita.
Il contesto applicativo: WooCommerce e personalizzazioni pesanti
L’e-commerce oggetto della consulenza contava circa 10.000 prodotti. Un catalogo importante, ma non eccezionale. Va detto che la base tecnologica era corretta: l’utilizzo di Varnish rappresenta infatti il golden standard indiscusso per qualsiasi architettura WooCommerce che necessiti di performance elevate e stabilità sotto carico. Non esiste, ad oggi, un acceleratore HTTP più efficace per gestire la natura dinamica di WordPress su grandi volumi.
Il tema, tuttavia, era fortemente personalizzato e aveva subito nel tempo numerosi interventi, soprattutto lato front-end, che avevano finito per erodere i benefici di questo stack. Prima ancora di parlare di cache, era evidente che il carico non derivasse tanto dal numero di prodotti quanto dal modo in cui le pagine venivano generate. In particolare, la struttura HTML risultava insolitamente pesante.
Come sempre, abbiamo deciso di partire da una misurazione oggettiva.
Le prime verifiche: osservare l’HTML senza filtri
Abbiamo effettuato richieste dirette alle pagine prodotto tramite curl, evitando volutamente qualsiasi negoziazione di compressione (come gzip o Brotli) o altre ottimizzazioni di trasporto. L’obiettivo non era simulare l’esperienza dell’utente finale, ma isolare e quantificare il “peso morto” dell’HTML generato dall’applicazione.
Il risultato è stato immediato e inequivocabile: circa 1,3 MB di codice HTML grezzo per singola pagina prodotto.
Un valore che, di per sé, rappresenta già un’anomalia. Ma diventa un problema critico se analizzato nell’architettura di una cache ad alte prestazioni come Varnish.
Perché 1,3 MB sono letali per Varnish
A differenza di sistemi di storage key-value come Redis — che possono essere configurati per ottimizzare la densità dei dati o gestire strutture compresse — Varnish opera con una filosofia architetturale completamente diversa, basata sulla velocità di I/O pura.
-
Nessuna Compressione in RAM: Varnish non comprime nativamente gli oggetti in memoria per risparmiare spazio (allocazione malloc). Il suo obiettivo è prendere il contenuto e restituirlo alla rete con il minor numero di cicli di CPU possibile. Salvare 1,3 MB significa occupare esattamente 1,3 MB di RAM per ogni singola variazione di pagina.
-
Latenza e Accesso alla Memoria: Varnish è progettato per gestire centinaia di migliaia di connessioni concorrenti. In questo scenario, l’accesso diretto alla memoria (RAM) deve essere istantaneo.
-
Spostare blocchi di memoria da 1,3 MB crea una pressione enorme sul bus di memoria.
-
Per mantenere la promessa di un Time-to-First-Byte (TTFB) inferiore al millisecondo, gli oggetti devono essere snelli.
-
In sintesi: dare in pasto a Varnish pagine da 1,3 MB significa trasformare una Ferrari in un autobus carico; il motore è potente, ma la massa da spostare rende impossibile raggiungere le prestazioni per cui è stato progettato.
Un chiarimento fondamentale: le immagini erano già escluse dalla cache
Durante la discussione è stato importante chiarire subito un punto: le immagini non erano il problema.
Come da best practices corrette, le immagini non venivano memorizzate in cache da Varnish, ma servite direttamente come asset statici da NGINX, beneficiando eventualmente della cache del browser o di sistemi esterni.
Questo significa che il peso osservato non era dovuto a JPEG, PNG o WebP, ma esclusivamente al markup HTML.
Un dettaglio tutt’altro che secondario, perché spesso si tende a imputare alle immagini un problema che nasce invece da scelte strutturali completamente diverse.
Inline CSS e componenti ripetitive: quando l’HTML esplode
Analizzando la sorgente delle pagine, è emerso che una parte consistente del peso era dovuta a:
- grandi blocchi di CSS inline
- menu complessi e strutture di navigazione iniettate direttamente nell’HTML
- componenti ripetitive identiche su ogni pagina prodotto
Tutto contenuto che, dal punto di vista architetturale, dovrebbe essere esternalizzato e riutilizzato, non duplicato migliaia di volte nel markup.
Questa scelta ha un impatto diretto su qualsiasi sistema di caching: ogni URL produce un oggetto enorme, unico, che occupa memoria preziosa.
Fare due conti: la cache non è una magia
A questo punto della consulenza siamo arrivati a un passaggio tanto semplice quanto spesso sottovalutato: fermarsi e fare due conti. Non benchmark complessi, non strumenti sofisticati, ma un calcolo elementare, di quelli che permettono immediatamente di inquadrare il problema nella giusta dimensione.
Se una singola pagina prodotto pesa circa 1,3 MB di solo HTML e il catalogo conta all’incirca 10.000 prodotti, il volume teorico dell’HTML potenzialmente cacheabile supera i 13 GB. È un dato puramente teorico, certo, ma estremamente utile per comprendere l’ordine di grandezza del sistema con cui si ha a che fare.
Questo non significa che tutte le pagine debbano o possano essere presenti contemporaneamente in cache. I pattern di traffico reali sono sempre più complessi: alcune pagine vengono richieste molto spesso, altre raramente, altre ancora quasi mai. Tuttavia, il numero fornisce un riferimento fondamentale per capire se le risorse messe a disposizione siano almeno compatibili con il carico potenziale.
A fronte di questo scenario, la configurazione di Varnish prevedeva circa 4 GB di RAM dedicata alla cache. Una quantità che, isolata dal contesto, potrebbe sembrare anche adeguata. Ma inserita in questo quadro, diventa evidente che non può contenere una porzione significativa del dataset cacheabile, soprattutto se gli oggetti sono così voluminosi.
È qui che cade uno dei miti più diffusi: la cache non è una magia. Non comprime automaticamente i problemi strutturali dell’applicazione, non “ottimizza” da sola contenuti eccessivamente pesanti e non può aggirare i limiti fisici delle risorse disponibili. Funziona entro confini ben definiti, e quando quei confini vengono superati, il suo comportamento resta comunque corretto, ma i benefici si riducono drasticamente.
Da questo punto in poi, il comportamento osservato — cache MISS frequenti, header Age che raramente cresce, benefici marginali — diventa perfettamente coerente. Non è il sintomo di un errore di configurazione o di un malfunzionamento, ma la conseguenza diretta di un rapporto squilibrato tra dimensione degli oggetti, quantità di contenuti e memoria allocata.
Ed è proprio in questo momento che il problema smette di essere “Varnish che non funziona” e diventa ciò che è realmente: un problema di proporzioni.
Cosa succede quando Varnish finisce la memoria
Quando la cache di Varnish raggiunge il limite della memoria disponibile, il processo non va in errore e non “si blocca”. Varnish è progettato per operare in condizioni di pressione costante e per gestire in modo autonomo la saturazione della cache. Quello che entra in gioco, in questi casi, è il suo meccanismo di eviction degli oggetti.
Dal punto di vista interno, Varnish mantiene una struttura di gestione degli oggetti cacheati basata su metadati che includono dimensione, tempo di creazione, TTL, grace e frequenza di accesso. Quando la memoria allocata alla cache viene saturata, Varnish deve liberare spazio per poter accettare nuovi oggetti. Lo fa applicando le proprie politiche di rimozione, che privilegiano l’eliminazione degli oggetti meno utili secondo i criteri stabiliti.
In pratica, gli oggetti più vecchi o meno frequentemente utilizzati vengono espulsi per fare spazio a quelli nuovi. Questo comportamento è corretto e previsto, ma assume un significato completamente diverso quando la dimensione media degli oggetti è molto elevata.
In uno scenario come quello analizzato, ogni singolo oggetto HTML occupa una quantità significativa di memoria. Di conseguenza, anche poche nuove richieste sono sufficienti a innescare un ciclo continuo di eviction. Un nuovo oggetto entra in cache, ma per farlo deve “spingere fuori” uno o più oggetti già presenti. Il risultato è una cache estremamente instabile, in cui il contenuto cambia continuamente.
Dal punto di vista operativo, questo porta a un comportamento ben definito:
- gli oggetti vengono inizialmente inseriti in cache
- la pressione sulla memoria cresce rapidamente
- oggetti appena cacheati vengono espulsi dopo poche richieste
- nuove richieste trovano la cache vuota o parzialmente svuotata
Questo ciclo si ripete costantemente, dando origine a un flusso continuo di MISS, non perché Varnish non stia cacheando, ma perché non riesce a mantenere gli oggetti abbastanza a lungo da renderli utili.
Un aspetto importante da comprendere è che, in queste condizioni, Varnish lavora più del necessario. Ogni oggetto viene comunque valutato, memorizzato temporaneamente, indicizzato e poi rimosso. Questo genera overhead aggiuntivo, senza però produrre un beneficio tangibile in termini di hit ratio.
Dal punto di vista di chi osserva il sistema dall’esterno, magari limitandosi agli header HTTP, il risultato è ingannevole. Si vedono risposte in MISS, un header Age che raramente supera pochi secondi e la percezione che la cache “non prenda mai”. In realtà, la cache sta funzionando in modo corretto, ma in condizioni che ne annullano l’efficacia.
È qui che emerge un punto fondamentale: una cache non è utile solo perché esiste, ma perché riesce a stabilizzare il carico. Quando la memoria è insufficiente rispetto alla dimensione e alla quantità degli oggetti cacheabili, questa stabilità viene meno. La cache diventa un sistema di passaggio temporaneo, anziché un vero strato di accelerazione.
Comprendere questo comportamento interno è essenziale per evitare diagnosi errate. Il problema non è l’algoritmo di Varnish, né una sua configurazione “sbagliata” in senso assoluto, ma il contesto in cui è stato inserito. Senza un dimensionamento coerente, anche il miglior algoritmo di caching è destinato a produrre risultati deludenti.
Il problema non era lo stack, ma il dimensionamento
Uno degli aspetti più interessanti emersi durante la consulenza è stato il criterio di dimensionamento della VPS.
La macchina era stata scelta principalmente in base allo spazio disco, probabilmente per ospitare media e database, mentre la RAM era stata considerata una risorsa secondaria.
Questo approccio può funzionare su un hosting tradizionale, ma diventa critico quando si introduce una cache HTTP in RAM.
Con Varnish nello stack, la memoria diventa una risorsa centrale, non accessoria.
In questo caso, la RAM allocata non era coerente né con il peso delle pagine né con il numero di URL coinvolti.
Le strade possibili: applicazione o infrastruttura
Una volta chiarite le cause, la consulenza si è spostata sulle soluzioni possibili.
Le opzioni erano essenzialmente due.
Intervenire sull’applicazione
La soluzione più corretta dal punto di vista architetturale prevedeva:
- riduzione drastica del CSS inline
- esternalizzazione degli stili comuni
- semplificazione dei menu e dei componenti ripetuti
- alleggerimento dell’HTML complessivo
Con pagine più leggere, la stessa quantità di RAM avrebbe potuto contenere molti più oggetti, rendendo la cache stabile ed efficace.
Adeguare l’infrastruttura
L’alternativa era intervenire sull’infrastruttura:
- aumentare significativamente la RAM dedicata a Varnish
- oppure configurare una cache su disco per estendere la capacità complessiva
Quest’ultima opzione non offre le stesse performance della RAM, ma consente a Varnish di continuare a funzionare in modo coerente anche con dataset molto grandi.
Cache su disco: non una scorciatoia, ma un compromesso
Durante la consulenza abbiamo dedicato tempo a chiarire un punto spesso frainteso, soprattutto nei contesti in cui le risorse infrastrutturali sono limitate: l’utilizzo dello storage su disco per la cache non rappresenta una “sconfitta” né una soluzione di ripiego mal progettata. È, piuttosto, una scelta consapevole che nasce dall’analisi dei vincoli reali del progetto.
La cache in RAM resta, per definizione, la soluzione ideale in termini di latenza e prestazioni. Tuttavia, non sempre è possibile — o economicamente sensato — allocare quantità di memoria sufficienti a contenere l’intero dataset cacheabile, soprattutto quando le pagine HTML sono molto pesanti o quando il numero di URL cresce rapidamente. In questi scenari, estendere la cache su disco permette a Varnish di continuare a svolgere il proprio ruolo in modo coerente, evitando un continuo ciclo di inserimenti ed espulsioni che rende la cache inefficace.
Naturalmente, si tratta di un compromesso: lo storage persistente non può offrire le stesse prestazioni della RAM e introduce una latenza maggiore. Ma è un compromesso che va valutato nel contesto complessivo, considerando il tipo di carico, la frequenza di accesso alle pagine e le aspettative realistiche di performance. L’errore non è utilizzare il disco per la cache, bensì farlo senza essere consapevoli delle sue implicazioni.
L’aspetto fondamentale è allineare le aspettative alla realtà tecnica. Quando si utilizza uno storage persistente, non ci si può attendere le stesse prestazioni della memoria volatile. Ma si può ottenere stabilità, prevedibilità e un miglioramento concreto rispetto a una cache che, pur essendo in RAM, è costantemente sotto pressione.
Il valore reale della consulenza tecnica
Il momento più significativo di questa esperienza non è stato tanto l’individuazione del problema, quanto il cambiamento di prospettiva che si è verificato durante il confronto.
All’inizio, la discussione ruotava attorno a un giudizio netto: uno strumento che “non funziona”. Con il progredire dell’analisi, però, il focus si è spostato gradualmente dai sintomi alle cause.
Una volta messi sul tavolo i numeri reali, le dimensioni effettive delle pagine, il consumo di memoria e il funzionamento interno di Varnish, la conversazione ha cambiato tono. È diventata finalmente una discussione tecnica, basata su dati oggettivi e non su percezioni o aspettative disattese.
Non si parlava più di “Varnish che non funziona”, ma di elementi concreti e misurabili:
- il peso dell’HTML generato dall’applicazione
- l’impatto di quel peso sulla cache in RAM
- le scelte di sviluppo che avevano portato a quella struttura
- il rapporto tra applicazione, reverse proxy e risorse disponibili
Ed è esattamente in questo passaggio che una consulenza porta valore reale. Non imponendo soluzioni, ma fornendo strumenti di lettura del problema. Non sostituendosi a chi gestisce il sistema, ma aiutandolo a interpretarne il comportamento.
Quando il dialogo si sposta dai giudizi agli indicatori, dalle opinioni ai numeri, le decisioni diventano più solide. Ed è in quel momento che diventa possibile scegliere consapevolmente se intervenire sull’applicazione, sull’infrastruttura o su entrambe, sapendo esattamente quali compromessi si stanno accettando.
Conclusione: prima i numeri, poi le decisioni
Cambiare tecnologia è spesso la scorciatoia più semplice. È una reazione comprensibile: quando qualcosa non funziona come ci si aspetta, la tentazione di sostituirlo con un’alternativa “più moderna”, “più semplice” o semplicemente diversa è forte. Tuttavia, nella stragrande maggioranza dei casi, questa scelta non risolve il problema alla radice. Lo sposta soltanto.
In ambito sistemistico e infrastrutturale, gli strumenti non operano nel vuoto. Ogni software, soprattutto quelli pensati per lavorare ad alte prestazioni come Varnish, esprime il proprio valore solo se inserito in un contesto coerente, progettato con cognizione di causa e dimensionato sulla base di dati reali. Senza questa base, anche la tecnologia migliore è destinata a sembrare inefficace.
Prima di sostituire uno strumento, è fondamentale comprenderne il funzionamento interno, i limiti strutturali e le condizioni in cui è stato pensato per operare. Nel caso specifico, il comportamento osservato non era il sintomo di un malfunzionamento, ma la conseguenza diretta di una serie di scelte applicative e infrastrutturali che, sommate tra loro, avevano reso la cache estremamente instabile.
Durante questa consulenza non abbiamo “difeso” Varnish per partito preso, né abbiamo sostenuto che fosse l’unica soluzione possibile. Abbiamo semplicemente fatto ciò che riteniamo indispensabile in ogni analisi tecnica: partire dai numeri. Dimensioni reali delle pagine, quantità di oggetti cacheabili, memoria disponibile, comportamento del sistema sotto carico. Tutti elementi misurabili, verificabili, oggettivi.
Ed è proprio quando i numeri entrano nella discussione che molte convinzioni iniziano a perdere forza. Una cache che sembra non funzionare, spesso, sta solo lavorando in condizioni per cui non è stata progettata. Un reverse proxy che restituisce molti MISS non è necessariamente mal configurato: potrebbe semplicemente essere sovraccarico di oggetti troppo grandi rispetto alle risorse disponibili.
Questa esperienza ci ha ricordato, ancora una volta, quanto sia pericoloso ragionare per slogan tecnologici. “Questo stack è migliore”, “questo software è più veloce”, “questo sistema cachea meglio”. Senza contesto, senza numeri e senza una visione d’insieme, sono affermazioni prive di reale valore tecnico.
Le ottimizzazioni che funzionano davvero, quelle che resistono nel tempo e accompagnano la crescita di un progetto, nascono sempre dalla comprensione profonda del sistema. Dall’equilibrio tra applicazione, infrastruttura e carico reale. Non dall’ennesimo cambio di stack, ma dalla capacità di leggere ciò che il sistema sta già dicendo.
Ed è esattamente in questo spazio — tra i numeri e le decisioni — che una consulenza tecnica può fare la differenza.
