Indice dei contenuti dell'articolo:
Sappiamo tutti che le prestazioni delle applicazioni e dei siti Web sono un fattore critico per il loro successo. Il processo per migliorare le prestazioni dell’applicazione o del sito Web, tuttavia, non è sempre chiaro. La qualità del codice e l’infrastruttura sono ovviamente fondamentali, ma in molti casi è possibile apportare notevoli miglioramenti all’esperienza dell’utente finale della propria applicazione concentrandosi su alcune tecniche di distribuzione delle applicazioni di base. Uno di questi esempi è l’implementazione e l’ottimizzazione della memorizzazione nella cache nello stack dell’applicazione. Questo post del blog copre le tecniche che possono aiutare sia gli utenti principianti che quelli avanzati a ottenere prestazioni migliori dall’utilizzo delle funzionalità della cache dei contenuti incluse in NGINX e NGINX Plus.
Panoramica
Una cache dei contenuti si trova tra un client e un “server di origine” e salva copie di tutto il contenuto che vede. Se un client richiede contenuto archiviato nella cache, restituisce il contenuto direttamente senza contattare il server di origine. Ciò migliora le prestazioni poiché la cache dei contenuti è più vicina al client e utilizza in modo più efficiente i server delle applicazioni perché non devono eseguire ogni volta il lavoro di generazione di pagine da zero.
Esistono potenzialmente più cache tra il browser Web e il server delle applicazioni: la cache del browser del client, le cache intermedie, le reti di distribuzione dei contenuti (CDN) e il servizio di bilanciamento del carico o proxy inverso che si trova davanti ai server delle applicazioni. La memorizzazione nella cache, anche a livello di proxy inverso/bilanciamento del carico, può migliorare notevolmente le prestazioni.
Ad esempio, la scorsa settimana ho assunto il compito di ottimizzare le prestazioni di un sito Web che si stava caricando lentamente. Una delle prime cose che ho notato è che ci è voluto più di 1 secondo per generare la home page principale. Dopo un po’ di debug, ho scoperto che, poiché la pagina era contrassegnata come non memorizzabile nella cache, veniva generata dinamicamente in risposta a ogni richiesta. La pagina stessa non cambiava molto spesso e non era personalizzata, quindi non era necessario. Come esperimento, ho contrassegnato la home page in modo che fosse memorizzata nella cache per 5 secondi dal servizio di bilanciamento del carico e il solo fatto ha comportato un notevole miglioramento. Il tempo per il primo byte è sceso a pochi millisecondi e la pagina è stata caricata visibilmente più velocemente.
Abbiamo parlato parecchio di NGINX Webserver e di come lo preferiamo per motivi di performance al più famoso Apache.
Tuttavia, abbiamo parlato poco di FastCGI Cache, utilizzando in azienda per la totalità dei clienti ad alte performance, Varnish Cache.
Stiamo comunque assistendo ad un’evoluzione di molti hosting provider che stanno proponendo FastCGI Cache come soluzione di Full Page Cache per il webserver NGINX
Non staremo qui a spiegare cosa sia una FPC (Full Page Cache n.d.r.) avendolo già fatto in diverse occasioni sul nostro blog, ma vogliamo entrare sin da subito nel vivo della questione parlando di FastCGI Cache che a prima vista può sembrare una soluzione di caching molto più facile di strumenti specifici di fascia enterprise come Varnish Cache.
Cos’è Nginx FastCGI Cache?
Prima di parlare di Nginx FastCGI Cache, parliamo di come funziona il tuo sito web.
- Quando un utente visita la tua pagina WordPress, il browser web invia una richiesta HTTP/HTTPS a Nginx.
- Nginx passa la richiesta a PHP-FPM e Nginx catturerà tutti i codici PHP quando proverà ad afferrare la pagina.
- PHP-FPM elabora la pagina ed esegue la query del database MariaDB/MySQL per recuperare la pagina.
- PHP-FPM invia la pagina HTML “statica” generata a Nginx.
- Nginx invia la pagina HTML generata al browser Web per l’utente.
NGINX include un modulo FastCGI che ha direttive per la memorizzazione nella cache di contenuti dinamici serviti dal backend PHP. L’impostazione elimina la necessità di ulteriori soluzioni di memorizzazione nella cache delle pagine come proxy inversi (pensa a Varnish ) o plug-in specifici dell’applicazione. Il contenuto può anche essere escluso dalla memorizzazione nella cache in base al metodo di richiesta, all’URL, ai cookie o a qualsiasi altra variabile del server.
Quando si utilizza Nginx FastCGI , questo modulo Nginx integrato si troverà tra Nginx e PHP-FPM ed è in grado di generare una pagina HTML memorizzata nella cache da PHP-FPM.
Quando un altro utente visita la stessa pagina WordPress, il tuo sito Web non eseguirà più le stesse richieste PHP e database perché la pagina è già memorizzata nella cache e servita da FastCGI.
Di conseguenza, il tempo di risposta del tuo server sarà molto più veloce dopo il caricamento iniziale.
Il tuo carico PHP-FPM e MariaDB/MySQL sarà ridotto.
L’utilizzo delle risorse della CPU del tuo server sarà inferiore.
E infine, il tuo server può gestire più traffico con le stesse specifiche del server quando usi Nginx FastCGI Cache, permettendoti in definitiva di mantenere un server più conveniente senza dover ridimensionare ulteriormente.
Il problema principale di NGINX FastCGI Cache nella versione free.
Va detto e ricordato che NGINX ha due modelli di distribuzione, la versione Free che tutti conoscono ed usiamo anche noi e la versione Plus chiamata NGINX Plus o NGINX + che è la versione commerciale a pagamento.
La differenza principale e la più importante tra le due versioni per ciò che concerne la cache FastCGI è che manca di default la funzionalità di PURGE ALL nella versione free.
Può capitare infatti di avere la necessità di cancellare tutta la cache in alcune configurazioni specifiche, immaginiamo un blog che ha nel footer i link delle ultime 5 notizie e alla scrittura di una nuova notizia si debba pulire tutta la cache di tutto il sito.
Mentre con Varnish basta mandare un BAN / o un PURGE ALL per pulire tutta la cache del sito con la stessa velocità di eseguire un’operazione di cancellazione sul Filesystem (forse meno di un secondo), con NGINX FastCGI Cache nella versione Free, avrai bisogno di richiamare una ad una a livello applicativo tutte le URL del tuo sito impiegando almeno 1 ora su un sito con 5000 pagine.
Ovviamente per risolvere questa problematica sono nati moduli per NGINX di terze parti che permettono di introdurre la funzionalità di PURGE ALL come, ad esempio, ngx_cache_purge che potete trovare a questo link : https://github.com/torden/ngx_cache_purge
Se non avete insomma le spalle larghe per installare un sistema di Caching Enterprise come Varnish, potete semplicemente optare per la versione Free con l’aggiunta di questo modulo.
