Ricerca nel sito web

Come memorizzare nella cache i contenuti in NGINX

NGINX è un server Web consolidato, open source e ad alte prestazioni che accelera la distribuzione di contenuti e applicazioni, aumenta la sicurezza e migliora la scalabilità. Uno dei casi d'uso più comuni di Nginx è il caching dei contenuti, che è il modo più efficace per aumentare le prestazioni di un sito web.

Leggi anche: 10 migliori strumenti di caching open source per Linux

Puoi utilizzare NGINX per accelerare i server di origine locale configurandolo per memorizzare nella cache le risposte dai server upstream e anche per creare server edge per reti di distribuzione dei contenuti (CDN). NGINX alimenta alcuni dei più grandi CDN.

Se configurato come cache, NGINX:

  • memorizzare nella cache contenuti statici e dinamici.
  • migliorare le prestazioni dei contenuti dinamici con il micro-caching.
  • fornire contenuti obsoleti riconvalidandoli in background per prestazioni migliori.
  • sovrascrivere o impostare intestazioni Cache-Control e altro ancora.

In questo articolo imparerai come configurare NGINX come caching 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, altrimenti segui queste guide per installare Nginx:

  • Come installare Nginx su CentOS 8
  • Come installare Nginx su CentOS 7

Memorizza nella cache i contenuti statici su Nginx

Il contenuto statico è il contenuto di un sito Web che rimane lo stesso (non cambia) su tutte le pagine. Esempi di contenuto statico includono file come immagini, video, documenti; File CSS e file JavaScript.

Se il tuo sito web fa uso di molti contenuti statici, puoi ottimizzarne le prestazioni abilitando la memorizzazione nella cache lato client in cui il browser memorizza copie di contenuti statici per un accesso più rapido.

La seguente configurazione di esempio è una buona soluzione, basta sostituire www.example.com con l'URL del nome del tuo sito web e apportare le modifiche appropriate agli altri nomi di percorso.

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;
    }
}

Memorizza nella cache i 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 archiviare il contenuto memorizzato 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 il contenuto dinamico su Nginx nella sezione seguente.

Abilitazione della cache FastCGI in NGINX

FastCGI (o FCGI) è un protocollo ampiamente utilizzato per interfacciare applicazioni interattive come PHP con server web come NGINX forte>. È un'estensione della CGI (Common Gateway Interface).

Il vantaggio principale di FCGI è che gestisce più richieste CGI in un unico processo. Senza di esso, il server web deve aprire un nuovo processo (che deve essere controllato, elaborare una richiesta e chiudersi) per ogni richiesta del client per un servizio.

Per elaborare gli script PHP in una distribuzione dello stack LEMP, 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 inoltrare le richieste per l'elaborazione. Pertanto NGINX può anche essere configurato per memorizzare nella cache le risposte dal server delle applicazioni backend PHP-FPM.

In NGINX, la cache dei contenuti FastCGI viene dichiarata utilizzando una direttiva chiamata fastcgi_cache_path nel http{} di livello superiore contesto, all'interno della struttura di configurazione NGINX. Puoi anche aggiungere fastcgi_cache_key che definisce una chiave (identificatore della richiesta) per la memorizzazione nella cache.

Inoltre, per leggere lo stato della cache upstream, aggiungi la direttiva add_header X-Cache-Status all'interno del contesto http{}: questo è utile per scopi di debug.

Supponendo che il file di configurazione del blocco server del tuo sito si trovi in /etc/nginx/conf.d/testapp.conf o /etc/nginx/sites-available/testapp.conf ( sotto Ubuntu e suoi derivati), apri il file di modifica 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 della directory del disco locale per la cache.
  • livelli – definisce i livelli gerarchici di una cache, imposta una gerarchia di directory a due livelli in /var/cache/nginx.
  • keys_zone (name:size) – consente la creazione di una zona di memoria condivisa in cui sono archiviate tutte le chiavi attive e le informazioni sui dati (meta). Tieni presente che la memorizzazione delle chiavi in memoria accelera il processo di controllo, rendendo più semplice per NGINX determinare se si tratta di un MISS o HIT, senza controllare lo stato sul disco.
  • inattivo: specifica il periodo di tempo dopo il quale i dati memorizzati nella cache a cui non si accede durante il periodo di tempo specificato vengono eliminati dalla cache indipendentemente dalla loro freschezza. Un valore di 60m nella nostra configurazione di esempio significa che i file a cui non si accede dopo 60 verranno rimossi dalla cache.
  • max_size – specifica la dimensione massima della cache. Ci sono più parametri che puoi usare qui (leggi la documentazione NGINX per maggiori informazioni).

Le variabili nella direttiva fastcgi_cache_key sono descritte di seguito.

NGINX li utilizza per calcolare la chiave (identificatore) di una richiesta. È importante sottolineare che per inviare una risposta memorizzata nella cache al client, la richiesta deve avere la stessa chiave di una risposta memorizzata nella cache.

  • $scheme: schema di richiesta, HTTP o HTTPS.
  • $request_method – metodo di richiesta, solitamente “GET” o “POST”.
  • $host: può essere il nome host dalla riga della richiesta o il nome host dal campo dell'intestazione della richiesta "Host" o il nome del server che corrisponde a una richiesta, in ordine di precedenza .
  • $request_uri: indica l'URI completo della richiesta originale (con argomenti).

Inoltre, la variabile $upstream_cache_status nella direttiva add_header X-Cache-Status viene calcolata per ogni richiesta a cui NGINX risponde, indipendentemente dal fatto che si tratti di un MISS (risposta non trovata nella cache, ottenuta dal server delle applicazioni) o un HIT (risposta fornita dalla cache) o uno qualsiasi degli altri valori supportati.

Successivamente, all'interno della direttiva location che passa le richieste PHP a PHP-FPM, utilizza le direttive fastcgi_cache per attivare la cache che hai appena definito sopra.

Imposta anche il tempo di memorizzazione nella cache per risposte diverse 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, verranno memorizzate nella cache solo le risposte 200, 301 e 302. Ma puoi anche specificare le risposte in modo esplicito o utilizzarne 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 di memorizzazione nella cache FastCGI su Nginx

Per impostare il numero minimo di volte in cui deve essere effettuata una richiesta con la stessa chiave prima che la risposta venga memorizzata nella cache, includere la direttiva fastcgi_cache_min_uses, nel campo http{} o contesto server{} o posizione{}.

fastcgi_cache_min_uses  3

Per abilitare la riconvalida degli elementi della cache scaduti utilizzando richieste condizionali con i campi di intestazione "If-Modified-Since" e "If-None-Match", aggiungi il fastcgi_cache_revalidate, all'interno del contesto http{} o server{} o location{}.

fastcgi_cache_revalidate on;

Puoi anche istruire NGINX a fornire il contenuto memorizzato nella cache quando il server di origine o il server FCGI è inattivo, utilizzando la direttiva proxy_cache_use_stale, all'interno della direttiva location.

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 nel contenuto memorizzato nella cache, consegna il file obsoleto.

proxy_cache_use_stale error timeout http_500;

Un'altra direttiva utile per ottimizzare le prestazioni della memorizzazione nella cache FCGI è fastcgi_cache_ background_update che funziona insieme alla direttiva proxy_cache_use_stale. Se impostato su attivo, indica a NGINX di fornire contenuto non aggiornato quando i client richiedono un file scaduto o in fase di aggiornamento dal server upstream.

fastcgi_cache_background_update on;

Anche fastcgi_cache_lock è utile per ottimizzare le prestazioni della cache in quanto se più client richiedono lo stesso contenuto che non è nella cache, NGINX inoltrerà solo la prima richiesta al server upstream, memorizzando nella cache il risposta quindi servire le altre richieste del client dalla cache.

fastcgi_cache_lock on;

Dopo aver apportato tutte le modifiche di cui sopra nel file di configurazione NGINX, salvalo e chiudilo. Controllare quindi la struttura di 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 tuo 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.linux-console.net

Ecco un altro screenshot che mostra NGINX che fornisce dati non aggiornati.

Aggiunta di eccezioni per bypassare la cache

È possibile impostare le condizioni alle quali NGINX non deve inviare risposte memorizzate nella cache ai client, utilizzando la direttiva fastcgi_cache_bypass. E per indicare a NGINX di non memorizzare affatto nella cache le risposte dal server upstream, utilizzare fastcgi_no_cache.

Ad esempio, se desideri che le richieste POST e gli URL con una stringa di query vadano sempre a PHP. Innanzitutto, dichiara un'istruzione if per impostare la condizione come segue.

set $skip_cache 0; 
if ($request_method = POST) { 
	set $skip_cache 1; 
}

Quindi attiva l'eccezione precedente nella direttiva location che passa le richieste PHP a PHP-FPM, utilizzando fastcgi_cache_bypass e fastcgi_no_cache direttive.

 
fastcgi_cache_bypass $skip_cache; 
fastcgi_no_cache $skip_cache;

Esistono molte altre parti del tuo sito per le quali potresti non voler abilitare la memorizzazione nella cache dei contenuti. Quello che segue è un esempio di configurazione NGINX per migliorare le prestazioni di un sito WordPress, fornito sul blog nginx.com.

Per usarlo, apporta modifiche (come dominio, percorsi, nomi di file, ecc.) per riflettere ciò che esiste nel tuo 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; 
	} 
}

Abilitazione della cache proxy in NGINX

NGINX supporta anche la memorizzazione nella cache delle risposte di altri server proxy (definiti dalla direttiva proxy_pass). Per questo caso di test, stiamo utilizzando NGINX come proxy inverso 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, includi la direttiva proxy_cache_path nel contesto http{} di livello superiore. Per specificare come le richieste vengono memorizzate nella cache, puoi anche 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, attiva la cache nella direttiva location.

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 contenuto memorizzato nella cache e non memorizza affatto nella cache una risposta dal server upstream, includere 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 proxy

Le seguenti direttive sono utili per ottimizzare le prestazioni della cache proxy. Hanno anche gli stessi significati 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 sulla configurazione della memorizzazione nella cache, consultare la documentazione per i due moduli principali ngx_http_fastcgi_module e ngx_http_proxy_module.

Risorse aggiuntive: memorizzazione nella cache dei contenuti NGINX e suggerimenti per migliorare le prestazioni di WordPress.