NGINX essendo un consolidato server web open source ad alte prestazioni che velocizza la distribuzione di contenuti e applicazioni, migliora la sicurezza e aumenta la scalabilità. Uno dei casi d’uso più comuni di Nginx è la Cache dei Contenuti, che è il modo più efficace per migliorare le prestazioni di un sito web.
Leggi anche: 10 Migliori Strumenti Open Source di Cache per Linux
Puoi utilizzare NGINX per accelerare i server di origine locali configurandolo per memorizzare nella cache le risposte dai server upstream e anche per creare server edge per le reti di distribuzione dei contenuti (CDN). NGINX alimenta alcune delle più grandi CDN.
Quando configurato come cache, NGINX:
- memorizzerà contenuti statici e dinamici.
- migliorerà le prestazioni dei contenuti dinamici con la micro-cache.
- servirà contenuti obsoleti mentre riconvalida in background per migliori prestazioni.
- sovrascriverà o imposterà gli header Cache-Control, e altro ancora.
In questo articolo, imparerai come configurare NGINX come Cache dei Contenuti in Linux per far funzionare i tuoi server web nel modo più efficiente possibile.
Prerequisiti:
Dovresti avere NGINX installato sul tuo server Linux, se non lo hai segui queste guide per installare Nginx:
Cache dei contenuti statici su Nginx
I contenuti statici sono contenuti di un sito web che rimangono gli stessi (non cambiano) tra le pagine. Esempi di contenuti statici includono file come immagini, video, documenti; file CSS e file JavaScript.
Se il tuo sito web fa largo uso di contenuti statici, puoi ottimizzarne le prestazioni abilitando la memorizzazione nella cache lato client, dove il browser memorizza copie dei contenuti statici per un accesso più veloce.
La seguente configurazione di esempio è un buon punto di partenza, sostituisci semplicemente www.example.com con l’URL del nome del tuo sito web e apporta le modifiche necessarie ad altri percorsi.
server {
# substitute your web server's URL for www.example.com
server_name www.example.com;
root /var/www/example.com/htdocs;
index index.php;
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
try_files $uri =404;
include fastcgi_params;
# substitute the socket, or address and port, of your WordPress server
fastcgi_pass unix:/var/run/php5-fpm.sock;
#fastcgi_pass 127.0.0.1:9000;
}
location ~* .(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg
|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid
|midi|wav|bmp|rtf)$ {
expires max;
log_not_found off;
access_log off;
}
}
Cache dei contenuti dinamici su Nginx
Nginx utilizza una cache persistente basata su disco situata da qualche parte nel file system locale. Quindi inizia creando la directory del disco locale per memorizzare i contenuti nella cache.
# mkdir -p /var/cache/nginx
Successivamente, imposta la proprietà appropriata sulla directory della cache. Dovrebbe essere di proprietà dell’utente Nginx (nginx) e del gruppo (nginx) come segue.
# chown nginx:nginx /var/cache/nginx
Ora procedi ulteriormente per vedere come abilitare i contenuti dinamici su Nginx nella sezione seguente.
Abilitare la cache FastCGI in Nginx
FastCGI (o FCGI) è un protocollo ampiamente utilizzato per l’interfacciamento di applicazioni interattive come PHP con server web come NGINX. Si tratta di un’estensione del CGI (Common Gateway Interface).
Il principale vantaggio del FCGI è che gestisce multiple richieste CGI in un singolo processo. Senza di esso, il web server deve aprire un nuovo processo (che deve essere controllato, elaborare una richiesta e chiudersi) per ogni richiesta di servizio da parte del client.
Per elaborare script PHP in un deployment LEMP stack, NGINX utilizza FPM (FastCGI Process Manager) o PHP-FPM, una popolare implementazione alternativa di PHP FastCGI. Una volta che il processo PHP-FPM è in esecuzione, NGINX è configurato per instradare le richieste ad esso per l’elaborazione. Così NGINX può anche essere configurato per memorizzare nella cache le risposte dal server dell’applicazione di backend
Sotto NGINX, la cache di contenuti FastCGI è dichiarata utilizzando una direttiva chiamata fastcgi_cache_path nel contesto http{} di alto livello, all’interno della struttura di configurazione di NGINX. È inoltre possibile aggiungere il fastcgi_cache_key che definisce una chiave (identificatore della richiesta) per la memorizzazione nella cache.
Inoltre, per leggere lo stato della cache di upstream, aggiungi la direttiva add_header X-Cache-Status all’interno del contesto http{} – questo è utile per scopi di debug.
Assumendo che il file di configurazione del blocco del server del tuo sito si trovi in /etc/nginx/conf.d/testapp.conf o /etc/nginx/sites-available/testapp.conf (sotto Ubuntu e le sue derivate), apri il file per modificarlo e aggiungi le seguenti righe all’inizio del file.
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=CACHEZONE:10m; inactive=60m max_size=40m; fastcgi_cache_key "$scheme$request_method$host$request_uri"; add_header X-Cache $upstream_cache_status;
La direttiva fastcgi_cache_path specifica il numero di parametri che sono:
- /var/cache/nginx – il percorso alla directory del disco locale per la cache.
- levels – definisce i livelli di gerarchia di una cache, impostando una gerarchia di directory a due livelli sotto /var/cache/nginx.
- keys_zone (nome:dimensione) – consente la creazione di una zona di memoria condivisa dove vengono memorizzate tutte le chiavi attive e le informazioni sui dati (meta). Si noti che memorizzare le chiavi in memoria velocizza il processo di verifica, facilitando a NGINX di determinare se si tratta di un MISS o di un HIT, senza controllare lo stato sul disco.
- inactive – specifica la quantità di tempo dopo la quale i dati memorizzati nella cache, non accessibili durante il tempo specificato, vengono eliminati indipendentemente dalla loro freschezza. Un valore di 60m nella nostra configurazione di esempio significa che i file non accessibili dopo 60 saranno rimossi dalla cache
- max_size – specifica la dimensione massima della cache. Ci sono più parametri che è possibile utilizzare qui (leggi la documentazione di NGINX per ulteriori informazioni).
Le variabili nella direttiva fastcgi_cache_key sono descritte di seguito.
NGINX le utilizza nel calcolare la chiave (identificatore) di una richiesta. È importante che, per inviare una risposta memorizzata nella cache al client, la richiesta debba avere la stessa chiave di una risposta memorizzata nella cache.
- $scheme – schema della richiesta, HTTP o HTTPS.
- $request_method – metodo della richiesta, di solito “GET” o “POST”.
- $host – può essere l’hostname dalla linea di richiesta, o l’hostname dall’intestazione di richiesta “Host”, o il nome del server corrispondente a una richiesta, nell’ordine di precedenza.
- $request_uri – significa l’URI della richiesta originale completo (con argomenti).
Inoltre, la variabile $upstream_cache_status nella direttiva add_header X-Cache-Status è calcolata per ogni richiesta a cui NGINX risponde, che sia un MISS (risposta non trovata nella cache, ottenuta dal server dell’applicazione) o un HIT (risposta servita dalla cache) o uno qualsiasi degli altri valori supportati.
Inoltre, all’interno della direttiva location che passa le richieste PHP a PHP-FPM, utilizza le direttive fastcgi_cache per attivare la cache appena definita sopra.
Imposta anche il tempo di memorizzazione nella cache per diverse risposte utilizzando la direttiva fastcgi_cache_valid come mostrato.
fastcgi_cache CACHEZONE; fastcgi_cache_valid 60m;
Se viene specificato solo il tempo di memorizzazione nella cache come nel nostro caso, vengono memorizzate solo le risposte 200, 301 e 302. Ma è anche possibile specificare esplicitamente le risposte o utilizzare qualsiasi (per qualsiasi codice di risposta):
fastcgi_cache CACHEZONE; fastcgi_cache_valid 200 301 203 60m; fastcgi_cache_valid 404 10m; OR fastcgi_cache CACHEZONE; fastcgi_cache_valid any 10m;
Ottimizzazione delle prestazioni della cache FastCGI su Nginx
Per impostare il numero minimo di volte in cui una richiesta con la stessa chiave deve essere effettuata prima che la risposta venga memorizzata nella cache, includere la direttiva fastcgi_cache_min_uses, sia nel contesto http{} che in server{} o location{}.
fastcgi_cache_min_uses 3
Per abilitare la ri-validazione degli elementi della cache scaduti utilizzando richieste condizionali con i campi intestazione “If-Modified-Since” e “If-None-Match“, aggiungere la direttiva fastcgi_cache_revalidate, all’interno del contesto http{} o server{} o location{}.
fastcgi_cache_revalidate on;
È anche possibile istruire NGINX a fornire contenuti memorizzati quando il server di origine o il server FCGI è inattivo, utilizzando la direttiva proxy_cache_use_stale, all’interno della direttiva di posizione.
Questa configurazione di esempio significa che quando NGINX riceve un errore, un timeout e uno qualsiasi degli errori specificati dal server upstream e ha una versione obsoleta del file richiesto nei contenuti memorizzati, viene fornito il file obsoleto.
proxy_cache_use_stale error timeout http_500;
Un’altra direttiva utile per ottimizzare le prestazioni della cache FCGI è fastcgi_cache_background_update, che funziona in congiunzione con la direttiva proxy_cache_use_stale. Quando impostato su on, istruisce NGINX a servire contenuti obsoleti quando i client richiedono un file scaduto o in fase di aggiornamento dal server upstream.
fastcgi_cache_background_update on;
Il fastcgi_cache_lock è anch’esso utile per ottimizzare le prestazioni della cache nel caso in cui più client richiedano lo stesso contenuto che non si trova in cache: NGINX inoltrerà solo la prima richiesta al server upstream, memorizzerà in cache la risposta e servirà le altre richiesta dei client dalla cache.
fastcgi_cache_lock on;
Dopo aver apportato tutte le modifiche nel file di configurazione di NGINX, salvalo e chiudilo. Controlla poi la struttura della configurazione per eventuali errori di sintassi prima di riavviare il servizio NGINX.
# nginx -t # systemctl restart nginx
Successivamente, verifica se la cache funziona correttamente, prova ad accedere alla tua applicazione web o al sito utilizzando il seguente comando curl (la prima volta dovrebbe indicare un MISS, ma le richieste successive dovrebbero indicare un HIT come mostrato nello screenshot).
# curl -I http://testapp.tecmint.com
Ecco un altro screenshot che mostra NGINX che serve dati obsoleti.
Aggiungere eccezioni per bypassare la cache
È possibile impostare condizioni in base alle quali NGINX non dovrebbe inviare risposte memorizzate nella cache ai client, utilizzando la direttiva fastcgi_cache_bypass. E per istruire NGINX a non memorizzare nella cache le risposte dal server di upstream, utilizzare il fastcgi_no_cache.
Per esempio, se si desidera che le richieste POST e gli URL con una stringa di query vadano sempre a PHP. Prima, dichiarare un’istruzione if per impostare la condizione come segue.
set $skip_cache 0;
if ($request_method = POST) {
set $skip_cache 1;
}
Attivare quindi l’eccezione sopra menzionata nella direttiva location che passa le richieste PHP a PHP-FPM, utilizzando le direttive fastcgi_cache_bypass e fastcgi_no_cache.
fastcgi_cache_bypass $skip_cache; fastcgi_no_cache $skip_cache;
Esistono molte altre parti del sito per le quali potrebbe non essere opportuno abilitare la memorizzazione nella cache dei contenuti. Di seguito è riportato un esempio di configurazione NGINX per migliorare le prestazioni di un sito WordPress, fornito nel blog nginx.com.
Per utilizzarlo, apportare modifiche (come il dominio, i percorsi, i nomi dei file, ecc.) per riflettere ciò che esiste nel proprio ambiente.
fastcgi_cache_path /var/run/NGINX-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
server {
server_name example.com www.example.com;
root /var/www/example.com;
index index.php;
access_log /var/log/NGINX/example.com.access.log;
error_log /var/log/NGINX/example.com.error.log;
set $skip_cache 0;
# POST requests and URLs with a query string should always go to PHP
if ($request_method = POST) {
set $skip_cache 1;
}
if ($query_string != "") {
set $skip_cache 1;
}
# Don't cache URIs containing the following segments
if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php |sitemap(_index)?.xml") {
set $skip_cache 1;
}
# Don't use the cache for logged-in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass |wordpress_no_cache|wordpress_logged_in") {
set $skip_cache 1;
}
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
try_files $uri /index.php;
include fastcgi_params;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 60m;
}
location ~ /purge(/.*) {
fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1";
}
location ~* ^.+.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg |gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi |wav|bmp|rtf)$ {
access_log off;
log_not_found off;
expires max;
}
location = /robots.txt {
access_log off;
log_not_found off;
}
location ~ /. {
deny all;
access_log off;
log_not_found off;
}
}
Abilitare la Cache Proxy in NGINX
NGINX supporta anche la memorizzazione nella cache delle risposte da altri server proxy (definiti dalla direttiva proxy_pass). Per questo caso di test, stiamo utilizzando NGINX come reverse proxy per un’applicazione web Node.js, quindi abiliteremo NGINX come cache per l’applicazione Node.js. Tutte le direttive di configurazione utilizzate qui hanno significati simili alle direttive FastCGI nella sezione precedente, quindi non le spiegheremo nuovamente.
Per abilitare la memorizzazione nella cache delle risposte da un server proxy, includere la direttiva proxy_cache_path nel contesto http{} di alto livello. Per specificare come vengono memorizzate le richieste, è anche possibile aggiungere la direttiva proxy_cache_key come segue.
proxy_cache_path /var/cache/nginx app1 keys_zone=PROXYCACHE:100m inactive=60m max_size=500m; proxy_cache_key "$scheme$request_method$host$request_uri"; add_header X-Cache-Status $upstream_cache_status; proxy_cache_min_uses 3;
Successivamente, attivare la cache nella direttiva di localizzazione.
location / {
proxy_pass http://127.0.0.1:3000;
proxy_cache PROXYCACHE;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
}
Per definire le condizioni in base alle quali NGINX non invia contenuti memorizzati e non memorizza affatto una risposta dal server upstream, includere le direttive proxy_cache_bypass e proxy_no_cache.
proxy_cache_bypass $cookie_nocache $arg_nocache$arg_comment; proxy_no_cache $http_pragma $http_authorization;
Ottimizzazione delle prestazioni della cache del proxy
Le seguenti direttive sono utili per ottimizzare le prestazioni della cache del proxy. Hanno anche lo stesso significato delle direttive FastCGI.
proxy_cache_min_uses 3; proxy_cache_revalidate on; proxy_cache_use_stale error timeout updating http_500; proxy_cache_background_update on; proxy_cache_lock on;
Per ulteriori informazioni e direttive di configurazione della cache, consultare la documentazione dei due principali moduli ngx_http_fastcgi_module e ngx_http_proxy_module.
Risorse aggiuntive: Memorizzazione nella Cache di NGINX e Suggerimenti per Migliorare le Prestazioni di WordPress.