Com emmagatzemar contingut a la memòria cau a NGINX


NGINX és un servidor web consolidat de codi obert i d'alt rendiment que accelera el lliurament de continguts i aplicacions, millora la seguretat i millora l'escalabilitat. Un dels casos d'ús més habituals de Nginx és la memòria cau de contingut, que és la forma més eficaç d'augmentar el rendiment d'un lloc web.

Podeu utilitzar NGINX per accelerar els servidors d'origen local configurant-lo per emmagatzemar a la memòria cau les respostes dels servidors amunt i també per crear servidors perifèrics per a xarxes de lliurament de contingut (CDN). NGINX alimenta alguns dels CDN més grans.

Quan es configura com a memòria cau, NGINX farà:

  • cacheu contingut estàtic i dinàmic a la memòria cau.
  • Millora el rendiment del contingut dinàmic amb la memòria cau.
  • publiceu contingut obsolet mentre es revalida en segon pla per obtenir un millor rendiment.
  • substituïu o configureu les capçaleres de control de memòria cau i molt més.

En aquest article, aprendràs a configurar NGINX com a memòria cau de contingut a Linux per fer que els teus servidors web funcionin de la manera més eficient possible.

Hauríeu de tenir NGINX instal·lat al vostre servidor Linux, si no, seguiu aquestes guies per instal·lar Nginx:

  • Com instal·lar Nginx a CentOS 8
  • Com instal·lar Nginx a CentOS 7

Emmagatzemar contingut estàtic a la memòria cau a Nginx

El contingut estàtic és el contingut d'un lloc web que segueix sent el mateix (no canvia) entre pàgines. Alguns exemples de contingut estàtic inclouen fitxers com ara imatges, vídeos, documents; Fitxers CSS i fitxers JavaScript.

Si el vostre lloc web fa ús de molt contingut estàtic, podeu optimitzar-ne el rendiment habilitant la memòria cau del costat del client on el navegador emmagatzema còpies del contingut estàtic per accedir-hi més ràpidament.

La configuració de mostra següent és una bona solució, només cal que substituïu www.example.com per l'URL del nom del vostre lloc web i feu modificacions a altres noms de camí segons correspongui.

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

Contingut dinàmic de la memòria cau a Nginx

NGINX utilitza una memòria cau persistent basada en disc ubicada en algun lloc del sistema de fitxers local. Per tant, comenceu creant el directori del disc local per emmagatzemar contingut a la memòria cau.
# mkdir -p /var/cache/nginx

A continuació, configureu la propietat adequada al directori de la memòria cau. Hauria de ser propietat de l'usuari NGINX (nginx) i del grup (nginx) de la manera següent.

# chown nginx:nginx /var/cache/nginx

Ara continueu per veure com habilitar el contingut dinàmic a Nginx a la secció següent.

Habilitació de la memòria cau FastCGI a NGINX

FastCGI (o FCGI) és un protocol molt utilitzat per connectar aplicacions interactives com PHP amb servidors web com NGINX. És una extensió de la CGI (Common Gateway Interface).

El principal avantatge de FCGI és que gestiona múltiples sol·licituds CGI en un sol procés. Sense ell, el servidor web ha d'obrir un nou procés (que s'ha de controlar, processar una sol·licitud i tancar-se) per a cada sol·licitud del client d'un servei.

Per processar scripts PHP en un desplegament de pila LEMP, NGINX utilitza FPM (FastCGI Process Manager) o PHP-FPM, una implementació alternativa de PHP FastCGI popular. Un cop s'executa el procés PHP-FPM, NGINX es configura per enviar-hi les sol·licituds per processar-les. Així, NGINX també es pot configurar per emmagatzemar a la memòria cau les respostes del servidor d'aplicacions de fons PHP-FPM.

Sota NGINX, la memòria cau de contingut FastCGI es declara mitjançant una directiva anomenada fastcgi_cache_path al context http{} de nivell superior, dins de l'estructura de configuració de NGINX. També podeu afegir la fastcgi_cache_key que defineix una clau (identificador de sol·licitud) per a la memòria cau.

A més, per llegir l'estat de la memòria cau amunt, afegiu la directiva add_header X-Cache-Status dins del context http{}; això és útil per a la depuració.

Suposant que el fitxer de configuració del bloc del servidor del vostre lloc es troba a /etc/nginx/conf.d/testapp.conf o /etc/nginx/sites-available/testapp.conf (a Ubuntu i els seus derivats), obriu el fitxer d'edició i afegiu-lo. les línies següents a la part superior del fitxer.

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 directiva fastcgi_cache_path especifica el nombre de paràmetres que són:

  • /var/cache/nginx: el camí al directori del disc local per a la memòria cau.
  • nivells: defineix els nivells de jerarquia d'una memòria cau, configura una jerarquia de directoris de dos nivells a /var/cache/nginx.
  • keys_zone (nom:mida): permet la creació d'una zona de memòria compartida on s'emmagatzemen totes les claus actives i la informació sobre les dades (meta). Tingueu en compte que emmagatzemar les claus a la memòria accelera el procés de comprovació, ja que és més fàcil que NGINX determini si és un MISS o un HIT, sense comprovar l'estat al disc.
  • inactiu: especifica la quantitat de temps després del qual les dades emmagatzemades a la memòria cau a les quals no s'accedeix durant el temps especificat s'eliminen de la memòria cau independentment de la seva actualització. Un valor de 60 m al nostre exemple de configuració significa que els fitxers als quals no s'accedeix després dels 60 s'eliminaran de la memòria cau.
  • max_size: especifica la mida màxima de la memòria cau. Hi ha més paràmetres que podeu utilitzar aquí (llegiu la documentació de NGINX per obtenir més informació).

Les variables de la directiva fastcgi_cache_key es descriuen a continuació.

NGINX els utilitza per calcular la clau (identificador) d'una sol·licitud. És important destacar que per enviar una resposta a la memòria cau al client, la sol·licitud ha de tenir la mateixa clau que una resposta a la memòria cau.

  • $scheme: esquema de sol·licitud, HTTP o HTTPS.
  • $request_method: mètode de sol·licitud, normalment \GET o \POST.
  • $host: pot ser el nom d'amfitrió de la línia de sol·licitud, o el nom d'amfitrió del camp de capçalera de la sol·licitud \Amfitrió, o el nom del servidor que coincideix amb una sol·licitud, per ordre de precedència.
  • $request_uri: significa l'URI de sol·licitud original complet (amb arguments).

A més, la variable $upstream_cache_status a la directiva add_header X-Cache-Status es calcula per a cada sol·licitud a la qual respon NGINX, tant si es tracta d'un MISS (resposta no trobada a la memòria cau, obtinguda del servidor d'aplicacions) o un HIT (resposta servida des de la memòria cau) o qualsevol dels altres valors admesos.

A continuació, dins de la directiva location que passa sol·licituds PHP a PHP-FPM, utilitza les directives fastcgi_cache per activar la memòria cau que acabeu de definir més amunt.

També configureu el temps de memòria cau per a diferents respostes utilitzant la directiva fastcgi_cache_valid com es mostra.

fastcgi_cache CACHEZONE;
fastcgi_cache_valid  60m;

Si només s'especifica el temps de memòria cau com en el nostre cas, només s'emmagatzemen a la memòria cau les respostes 200, 301 i 302. Però també podeu especificar les respostes de manera explícita o utilitzar-ne qualsevol (per a qualsevol codi de resposta):

fastcgi_cache CACHEZONE;
fastcgi_cache_valid 200  301 203 60m;
fastcgi_cache_valid 404 10m;
OR
fastcgi_cache CACHEZONE;
fastcgi_cache_valid  any 10m;

Ajustar el rendiment de la memòria cau FastCGI a Nginx

Per establir el nombre mínim de vegades que s'ha de fer una sol·licitud amb la mateixa clau abans d'emmagatzemar la resposta a la memòria cau, incloeu la directiva fastcgi_cache_min_uses, ja sigui a http{} o a context >servidor{} o ubicació{}.

fastcgi_cache_min_uses  3

Per habilitar la revalidació dels elements de la memòria cau caducats mitjançant sol·licituds condicionals amb els camps de capçalera \If-Modified-Since i \If-None-Match, afegiu la directiva fastcgi_cache_revalidate dins del http{} o servidor{} o ubicació{}.

fastcgi_cache_revalidate on;

També podeu indicar a NGINX que proporcioni contingut a la memòria cau quan el servidor d'origen o el servidor FCGI estiguin inactivats, utilitzant la directiva proxy_cache_use_stale dins de la directiva d'ubicació.

Aquesta configuració de mostra significa que quan NGINX rep un error, temps d'espera i qualsevol dels errors especificats del servidor amunt i té una versió obsoleta del fitxer sol·licitat al contingut de la memòria cau, lliura el fitxer obsolet.

proxy_cache_use_stale error timeout http_500;

Una altra directiva útil per ajustar el rendiment de la memòria cau FCGI és fastcgi_cache_background_update que funciona conjuntament amb la directiva proxy_cache_use_stale. Quan s'activa, indica a NGINX que serveixi contingut obsolet quan els clients sol·liciten un fitxer que ha caducat o està en procés d'actualització des del servidor amunt.

fastcgi_cache_background_update on;

El fastcgi_cache_lock també és útil, per a l'ajustament del rendiment de la memòria cau, ja que si diversos clients demanen el mateix contingut que no es troba a la memòria cau, NGINX només reenviarà la primera sol·licitud al servidor amunt, emmagatzema la memòria cau la resposta i després servir les altres peticions del client des de la memòria cau.

fastcgi_cache_lock on;

Després de fer tots els canvis anteriors al fitxer de configuració NGINX, deseu-lo i tanqueu-lo. A continuació, comproveu l'estructura de configuració per detectar qualsevol error de sintaxi abans de reiniciar el servei NGINX.

# nginx -t
# systemctl restart nginx

A continuació, comproveu si la memòria cau funciona correctament, proveu d'accedir a la vostra aplicació web o lloc mitjançant l'ordre curl següent (la primera vegada hauria d'indicar un MISS, però les sol·licituds posteriors haurien d'indicar un HIT com es mostra a la captura de pantalla).

# curl -I http://testapp.linux-console.net

Aquí hi ha una altra captura de pantalla que mostra que NGINX ofereix dades obsoletes.

Afegeix excepcions a la memòria cau de bypass

És possible establir condicions sota les quals NGINX no hauria d'enviar respostes a la memòria cau als clients, utilitzant la directiva fastcgi_cache_bypass. I per indicar a NGINX que no emmagatzemi en memòria cau les respostes del servidor amunt, utilitzeu el fastcgi_no_cache.

Per exemple, si voleu que les sol·licituds POST i els URL amb una cadena de consulta sempre vagin a PHP. Primer, declareu una instrucció if per establir la condició de la següent manera.

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

A continuació, activeu l'excepció anterior a la directiva location que passa sol·licituds PHP a PHP-FPM, utilitzant les directives fastcgi_cache_bypass i fastcgi_no_cache.

 
fastcgi_cache_bypass $skip_cache; 
fastcgi_no_cache $skip_cache;

Hi ha moltes altres parts del vostre lloc per a les quals potser no vulgueu habilitar la memòria cau de contingut. El següent és un exemple de configuració de NGINX per millorar el rendiment d'un lloc de WordPress, que es proporciona al bloc nginx.com.

Per utilitzar-lo, feu canvis (com ara el domini, els camins, els noms de fitxer, etc.) per reflectir el que hi ha al vostre entorn.

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

Habilitant la memòria cau del servidor intermediari a NGINX

NGINX també admet l'emmagatzematge a la memòria cau de les respostes d'altres servidors intermediaris (definit per la directiva proxy_pass). Per a aquest cas de prova, estem utilitzant NGINX com a servidor intermediari invers per a una aplicació web Node.js, de manera que habilitarem NGINX com a memòria cau per a l'aplicació Node.js. Totes les directives de configuració utilitzades aquí tenen significats similars a les directives FastCGI de la secció anterior, de manera que no les tornarem a explicar.

Per habilitar l'emmagatzematge en memòria cau de les respostes d'un servidor intermediari, incloeu la directiva proxy_cache_path al context http{} de nivell superior. Per especificar com s'emmagatzemen les sol·licituds a la memòria cau, també podeu afegir la directiva proxy_cache_key de la següent manera.

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;

A continuació, activeu la memòria cau a la directiva d'ubicació.

location / {
	proxy_pass http://127.0.0.1:3000;
	proxy_cache        PROXYCACHE;
	proxy_cache_valid 200 302 10m;
	proxy_cache_valid 404      1m;
}

Per definir les condicions sota les quals NGINX no envia contingut a la memòria cau i no guarda cap resposta des del servidor amunt, inclou el proxy_cache_bypass i el proxy_no_cache.

 
proxy_cache_bypass  $cookie_nocache $arg_nocache$arg_comment;
proxy_no_cache        $http_pragma $http_authorization;

Ajustar el rendiment de la memòria cau del servidor intermediari

Les instruccions següents són útils per ajustar el rendiment de la memòria cau del servidor intermediari. També tenen els mateixos significats que les directives 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 obtenir més informació i les directives de configuració de la memòria cau, consulteu la documentació dels dos mòduls principals ngx_http_proxy_module.

Recursos addicionals: consells per millorar el rendiment de WordPress.