NGINX Proxy Cache vs FastCGI Cache: stesso motore, due posizioni diverse. Quale scegliere?

Quando si parla di cache con NGINX, prima o poi arriva la domanda: meglio la Proxy Cache o la FastCGI Cache? Online si trovano confronti, benchmark e opinioni contrastanti, spesso basati sull’idea che una delle due sia “più veloce” dell’altra. È una domanda impostata male. Le due cache usano lo stesso motore, conservano i dati nello stesso modo e rispondono con la stessa velocità. Quello che cambia è dove si trovano nell’architettura e quindi quali problemi sono in grado di risolvere.

In questo articolo spiego cosa sono, in cosa si somigliano, dove si differenziano davvero e quando conviene l’una o l’altra, con un occhio a come le usiamo nella pratica sui server che gestiamo, compreso quello che pubblica questo sito.

Lo stesso motore, due posizioni diverse

NGINX ha un unico meccanismo di cache, che può essere collegato a diversi tipi di backend. Le due varianti più usate sono queste:

• la Proxy Cache si usa quando NGINX lavora come reverse proxy e inoltra le richieste a un altro server HTTP: un Apache, un secondo NGINX, un’applicazione Node.js o Java, un Varnish, un server su un’altra macchina;
• la FastCGI Cache si usa quando NGINX parla direttamente con l’interprete dell’applicazione attraverso il protocollo FastCGI, tipicamente PHP-FPM per WordPress, WooCommerce, PrestaShop, Magento o Laravel.

In entrambi i casi il principio è identico: la prima volta che una pagina viene richiesta, NGINX la chiede al backend, la consegna al visitatore e ne conserva una copia. Le richieste successive per la stessa pagina vengono servite da quella copia, senza disturbare il backend, finché la copia è valida.

Anche il modo di conservare i dati è lo stesso. Le pagine vengono salvate come file su disco, mentre l’elenco delle chiavi e le informazioni su ciascuna copia stanno in una zona di memoria condivisa tra i processi di NGINX. In pratica, grazie alla cache del sistema operativo, le pagine più richieste restano in RAM e vengono servite quasi senza toccare il disco. Le prestazioni di una risposta servita dalla cache sono quindi equivalenti: in entrambi i casi è NGINX che legge una copia già pronta.

Le funzioni in comune

Le due cache condividono anche tutte le funzioni che contano in produzione:

• regole su cosa conservare e per quanto, in base al codice di risposta, alle intestazioni inviate dal backend o a durate decise dal sistemista;
• esclusioni per utenti autenticati, carrelli, aree riservate e richieste diverse da una semplice lettura;
• protezione dalle corse: quando una pagina scade e arrivano cento richieste insieme, una sola va al backend a rigenerarla e le altre aspettano, invece di colpire tutte insieme PHP o il database;
• servizio della copia scaduta: mentre la nuova versione viene preparata, o se il backend è momentaneamente in errore, NGINX può continuare a servire la copia precedente. È una delle funzioni più preziose, perché trasforma un backend lento o in difficoltà in un sito che continua a rispondere;
• aggiornamento in background, che rigenera la pagina scaduta senza far attendere il visitatore.

C’è anche un limite comune, che è giusto conoscere: nella versione open source di NGINX non esiste la cancellazione mirata di una singola pagina. La funzione di “purge” fa parte dell’abbonamento commerciale di NGINX Plus; sulla versione libera si ricorre a moduli di terze parti oppure si progetta la cache con durate brevi. È una delle ragioni per cui, dove serve invalidare con precisione, mettiamo Varnish nella catena.

Dove sta la differenza vera

Se il motore è lo stesso, la differenza sta in tre aspetti pratici.

1. Il numero di passaggi

Con la FastCGI Cache, NGINX parla direttamente con PHP-FPM: richiesta del visitatore, NGINX, PHP. Non ci sono intermediari. Con la Proxy Cache davanti a un’applicazione PHP serve invece un passaggio in più: NGINX inoltra la richiesta via HTTP a un altro server web, che a sua volta la passa a PHP. Sulle pagine servite dalla cache la differenza non si vede; sui MISS c’è un piccolo costo aggiuntivo, quasi sempre trascurabile rispetto al tempo di generazione della pagina, ma che su un solo server non porta alcun vantaggio.

2. Cosa c’è dietro

La FastCGI Cache ha senso solo se dietro c’è un processo FastCGI. La Proxy Cache funziona davanti a qualsiasi cosa parli HTTP: un altro server, un’applicazione in un container, un servizio su un’altra macchina, un intero cluster. Per questo è lo strumento naturale delle architetture a più livelli, dei nodi di bordo che servono contenuti di server lontani, delle applicazioni non PHP.

3. Chi decide la durata

In entrambi i casi la cache può rispettare le intestazioni inviate dall’applicazione oppure ignorarle e seguire regole del sistemista. Nella pratica, però, con la FastCGI Cache la configurazione vive sullo stesso server dell’applicazione e chi la gestisce conosce il CMS; con la Proxy Cache spesso si trova su un livello separato, magari gestito da un team diverso, e diventa fondamentale che l’applicazione comunichi in modo corretto cosa si può conservare e cosa no.

Quando scegliere la FastCGI Cache

La FastCGI Cache è la scelta più semplice ed efficace quando:

• c’è un solo server con NGINX e PHP-FPM, come nella maggior parte dei siti WordPress e dei piccoli e-commerce;
• si vuole il percorso più corto possibile tra visitatore e applicazione, senza servizi aggiuntivi da mantenere;
• le pagine pubbliche sono tante e uguali per tutti i visitatori anonimi, e le pagine personali sono riconoscibili da un cookie.

È anche il modo più rapido per dare respiro a un sito in difficoltà durante un picco di traffico: pochi secondi di cache sulle pagine pubbliche bastano a ridurre drasticamente il numero di processi PHP impegnati.

Quando scegliere la Proxy Cache

La Proxy Cache è la scelta giusta quando:

• dietro NGINX non c’è PHP-FPM ma un altro server HTTP, un’applicazione in Node.js, Python o Java, o un servizio su un’altra macchina;
• l’architettura è a più livelli: un NGINX di bordo che termina HTTPS e protegge l’infrastruttura, uno o più livelli interni, magari un Varnish;
• si vuole mettere una cache davanti a un sistema esistente senza modificarlo, per esempio un vecchio server Apache che non si può migrare subito.

La microcache: pochi secondi che salvano il server

Una tecnica che usiamo spesso, con entrambe le cache, è la microcache: conservare le pagine per pochissimi secondi. Può sembrare inutile, ma pensiamo a una pagina richiesta cento volte al secondo durante una campagna o un’uscita in TV. Con una cache di un solo secondo, il backend la genera una volta al secondo invece di cento. Il contenuto resta di fatto sempre aggiornato, mentre il carico crolla.

È la stessa logica che applichiamo sul nostro sito. Davanti a tutto c’è un NGINX che termina HTTPS e tiene una microcache delle pagine pubbliche, con una copia per ciascun tipo di compressione richiesto dai browser. Dietro c’è Varnish, che gestisce la cache vera e propria con le sue regole e la possibilità di invalidare le pagine, e solo dopo arriva il server che esegue PHP. Il livello NGINX di bordo, in questo schema, è proprio una Proxy Cache: davanti non ha PHP, ha un altro server HTTP.

Gli errori più comuni

Qualunque cache si scelga, i problemi che vediamo più spesso nei siti che ci vengono affidati sono sempre gli stessi:

• chiavi di cache troppo povere, che non distinguono tra versioni diverse della stessa pagina: desktop e mobile, lingue, valute, compressioni. Il risultato è un visitatore che riceve la versione sbagliata;
• pagine personali messe in cache: carrelli, aree clienti, nomi utente mostrati nell’intestazione. Bastano pochi minuti di una configurazione sbagliata per mostrare a un cliente i dati di un altro;
• cookie che rendono tutto non conservabile: per impostazione predefinita NGINX non mette in cache le risposte che impostano un cookie, e molte applicazioni ne impostano uno a ogni pagina anche quando non serve. La cache c’è, ma non viene mai usata;
• nessuna protezione dalle corse: allo scadere di una pagina molto richiesta, decine di richieste arrivano tutte insieme al backend e il server va in affanno proprio quando la cache dovrebbe proteggerlo;
• nessuna misura: senza osservare quante richieste vengono servite dalla cache e quante arrivano al backend, non si sa se la cache stia funzionando o se sia solo un costo in più.

E Varnish?

Le cache di NGINX sono eccellenti per ridurre il carico in modo semplice. Varnish resta superiore quando serve un controllo fine: regole complesse scritte in un linguaggio dedicato, invalidazione precisa di singole pagine o di gruppi di pagine, gestione elaborata di varianti e cookie. Non è un’alternativa esclusiva: nelle architetture che gestiamo le cache di NGINX e Varnish lavorano spesso insieme, ognuna nel punto in cui rende di più. Ne abbiamo parlato, per esempio, negli articoli su Joomla e Varnish e su Drupal e le cache tag.

Conclusioni

“Proxy Cache o FastCGI Cache?” non è una gara di velocità. Le due cache sono lo stesso strumento collegato in due punti diversi: la FastCGI Cache accorcia il percorso quando NGINX e PHP stanno sullo stesso server, la Proxy Cache permette di mettere una cache davanti a qualsiasi backend e di costruire architetture a più livelli. La scelta dipende dall’architettura, non dal benchmark. E in entrambi i casi la differenza tra una cache utile e una cache inutile, o pericolosa, la fanno le regole: cosa conservare, per chi, per quanto, e come comportarsi quando il backend rallenta.

Se vuoi capire quale cache serve al tuo progetto, o perché quella che hai non sembra fare effetto, con il nostro servizio di assistenza NGINX analizziamo l’architettura e la configuriamo su misura, e sui nostri Server Dedicati la troviamo già pronta e ottimizzata.