Cómo almacenar en caché el contenido en NGINX


NGINX es un servidor web consolidado de código abierto y alto rendimiento que acelera la entrega de contenido y aplicaciones, mejora la seguridad y mejora la escalabilidad. Uno de los casos de uso más comunes de Nginx es el almacenamiento en caché de contenido, que es la forma más efectiva de mejorar el rendimiento de un sitio web.

Puede usar NGINX para acelerar los servidores de origen local configurándolo para almacenar en caché las respuestas de los servidores ascendentes y también para crear servidores de borde para redes de entrega de contenido (CDN). NGINX impulsa algunas de las CDN más grandes.

Cuando se configura como caché, NGINX:

  • cache static and dynamic content.
  • improve dynamic content performance with micro-caching.
  • serve stale content while revalidating in the background for better performance.
  • override or set Cache-Control headers, and more.

En este artículo, aprenderá cómo configurar NGINX como almacenamiento en caché de contenido en Linux para que sus servidores web funcionen de la manera más eficiente posible.

Debería tener NGINX instalado en su servidor Linux, si no, siga estas guías para instalar Nginx:

Almacenamiento en caché de contenido estático en Nginx

El contenido estático es el contenido de un sitio web que permanece igual (no cambia) en todas las páginas. Los ejemplos de contenido estático incluyen archivos como imágenes, videos, documentos; Archivos CSS y archivos JavaScript.

Si su sitio web utiliza una gran cantidad de contenido estático, puede optimizar su rendimiento habilitando el almacenamiento en caché del lado del cliente donde el navegador almacena copias de contenido estático para un acceso más rápido.

La siguiente configuración de muestra es una buena opción, simplemente reemplace www.example.com con la URL del nombre de su sitio web y realice modificaciones en otras rutas según corresponda.

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

Almacenamiento en caché de contenido dinámico en Nginx

# mkdir -p/var/cache/nginx

A continuación, establezca la propiedad adecuada en el directorio de caché. Debe ser propiedad del usuario NGINX (nginx) y del grupo (nginx) de la siguiente manera.

# chown nginx:nginx /var/cache/nginx

Ahora continúe para ver cómo habilitar el contenido dinámico en Nginx en la siguiente sección.

Habilitación de FastCGI Cache en NGINX

FastCGI (o FCGI) es un protocolo ampliamente utilizado para interconectar aplicaciones interactivas como PHP con servidores web como NGINX. Es una extensión de CGI (Common Gateway Interface).

La principal ventaja de FCGI es que administra múltiples solicitudes CGI en un solo proceso. Sin él, el servidor web tiene que abrir un nuevo proceso (que debe ser controlado, procesar una solicitud y cerrarse) para cada solicitud de servicio de un cliente.

Para procesar scripts PHP en una implementación de pila LEMP, NGINX usa FPM (FastCGI Process Manager) o PHP-FPM, una popular implementación alternativa de PHP FastCGI. Una vez que se está ejecutando el proceso PHP-FPM, NGINX se configura para enviar solicitudes de proxy para su procesamiento. Por lo tanto, NGINX también se puede configurar para almacenar en caché las respuestas del servidor de aplicaciones backend PHP-FPM.

Bajo NGINX, la caché de contenido FastCGI se declara usando una directiva llamada fastcgi_cache_path en el contexto de nivel superior http {} , dentro de la estructura de configuración de NGINX. También puede agregar el fastcgi_cache_key que define una clave (identificador de solicitud) para el almacenamiento en caché.

Además, para leer el estado de la caché ascendente, agregue la directiva add_header X-Cache-Status dentro del contexto http {} ; esto es útil para fines de depuración.

Suponiendo que el archivo de configuración del bloque del servidor de su sitio se encuentra en /etc/nginx/conf.d/testapp.conf o /etc/nginx/sites-available/testapp.conf (en Ubuntu y sus derivados), abra el archivo de edición y agregue las siguientes líneas en la parte superior del archivo.

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 número de parámetros que son:

  • /var/cache/nginx – the path to the local disk directory for the cache.
  • levels – defines the hierarchy levels of a cache, it sets up a two-level directory hierarchy under /var/cache/nginx.
  • keys_zone (name:size) – enables the creation of a shared memory zone where all active keys and information about data (meta) are stored. Note that storing the keys in memory speeds up the checking process, by making it easier for NGINX to determine whether its a MISS or HIT, without checking the status on disk.
  • inactive – specifies the amount of time after which cached data that are not accessed during the time specified get deleted from the cache regardless of their freshness. A value of 60m in our example configuration means files not accessed after 60 will get removed from the cache.
  • max_size – specifies the maximum size of the cache. There are more parameters you can use here (read the NGINX documentation for more information).

Las variables de la directiva fastcgi_cache_key se describen a continuación.

NGINX los usa para calcular la clave (identificador) de una solicitud. Es importante destacar que para enviar una respuesta en caché al cliente, la solicitud debe tener la misma clave que una respuesta en caché.

  • $scheme – request scheme, HTTP or HTTPS.
  • $request_method – request method, usually “GET” or “POST”.
  • $host – this can be hostname from the request line, or hostname from the “Host” request header field, or the server name matching a request, in the order of precedence.
  • $request_uri – means the full original request URI (with arguments).

Además, la variable en la directiva add_header X-Cache-Status se calcula para cada solicitud a la que responde NGINX, ya sea una MISS (respuesta no encontrada en la caché, obtenida del servidor de aplicaciones) o una HIT (respuesta servida desde la caché) o cualquiera de los otros valores admitidos.

A continuación, dentro de la directiva location que pasa solicitudes PHP a PHP-FPM, utiliza las directivas fastcgi_cache para activar la caché que acaba de definir anteriormente.

También configure el tiempo de almacenamiento en caché para diferentes respuestas usando la directiva fastcgi_cache_valid como se muestra.

fastcgi_cache CACHEZONE;
fastcgi_cache_valid  60m;

Si solo se especifica el tiempo de almacenamiento en caché como en nuestro caso, solo se almacenan en caché las respuestas 200, 301 y 302. Pero también puede especificar las respuestas explícitamente o usar cualquiera (para cualquier código de respuesta):

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

Ajuste del rendimiento del almacenamiento en caché FastCGI en Nginx

Para establecer el número mínimo de veces que se debe realizar una solicitud con la misma clave antes de que la respuesta se almacene en caché, incluya la directiva fastcgi_cache_min_uses , ya sea en http {} o servidor {} o ubicación {} contexto.

fastcgi_cache_min_uses  3

Para habilitar la revalidación de elementos de caché caducados mediante solicitudes condicionales con los campos de encabezado "If-Modified-Since" y "If-None-Match", agregue la directiva fastcgi_cache_revalidate , dentro del http {} o servidor {} o ubicación {} contexto.

fastcgi_cache_revalidate on;

También puede indicarle a NGINX que entregue contenido en caché cuando el servidor de origen o el servidor FCGI esté inactivo, utilizando la directiva proxy_cache_use_stale , dentro de la directiva de ubicación.

Esta configuración de muestra significa que cuando NGINX recibe un error, un tiempo de espera y cualquiera de los errores especificados del servidor ascendente y tiene una versión obsoleta del archivo solicitado en el contenido en caché, entrega el archivo obsoleto.

proxy_cache_use_stale error timeout http_500;

Otra directiva útil para ajustar el rendimiento del almacenamiento en caché de FCGI es fastcgi_cache_background_update que funciona en conjunto con la directiva proxy_cache_use_stale . Cuando está activado, le indica a NGINX que proporcione contenido obsoleto cuando los clientes soliciten un archivo caducado o en proceso de actualización desde el servidor ascendente.

fastcgi_cache_background_update on;

El fastcgi_cache_lock también es útil, para el ajuste fino del rendimiento de la caché, ya que si varios clientes solicitan el mismo contenido que no está en la caché, NGINX solo reenviará la primera solicitud al servidor ascendente, almacenará en caché el La respuesta luego sirve a las otras solicitudes del cliente desde la caché.

fastcgi_cache_lock on;

Después de realizar todos los cambios anteriores en el archivo de configuración de NGINX, guárdelo y ciérrelo. Luego, verifique la estructura de configuración para detectar errores de sintaxis antes de reiniciar el servicio NGINX.

# nginx -t
# systemctl restart nginx

A continuación, pruebe si la caché está funcionando correctamente, intente acceder a su aplicación web o sitio usando el siguiente comando curl (la primera vez debería indicar un FALTA, pero las solicitudes posteriores deberían indicar un HIT como se muestra en la captura de pantalla).

# curl -I http://testapp.tecmint.com

Aquí hay otra captura de pantalla que muestra a NGINX sirviendo datos obsoletos.

Agregar excepciones para omitir la caché

Es posible establecer condiciones bajo las cuales NGINX no debe enviar respuestas en caché a los clientes, usando la directiva fastcgi_cache_bypass . Y para indicarle a NGINX que no almacene en caché las respuestas del servidor ascendente, use el fastcgi_no_cache .

Por ejemplo, si desea que las solicitudes POST y las URL con una cadena de consulta vayan siempre a PHP. Primero, declare una instrucción if para establecer la condición de la siguiente manera.

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

Luego active la excepción anterior en la directiva location que pasa solicitudes PHP a PHP-FPM, usando las directivas fastcgi_cache_bypass y fastcgi_no_cache .

 
fastcgi_cache_bypass $skip_cache; 
fastcgi_no_cache $skip_cache;

Hay muchas otras partes de su sitio para las que es posible que no desee habilitar el almacenamiento en caché de contenido. La siguiente es una configuración de ejemplo de NGINX para mejorar el rendimiento de un sitio de WordPress, proporcionada en el blog nginx.com.

Para usarlo, realice cambios (como el dominio, las rutas, los nombres de archivo, etc.) para reflejar lo que existe en su entorno.

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

Habilitación de la caché de proxy en NGINX

NGINX también admite el almacenamiento en caché de respuestas de otros servidores proxy (definidos por la directiva proxy_pass ). Para este caso de prueba, estamos usando NGINX como un proxy inverso para una aplicación web Node.js, por lo que habilitaremos NGINX como caché para la aplicación Node.js. Todas las directivas de configuración utilizadas aquí tienen significados similares a las directivas FastCGI en la sección anterior, por lo que no las explicaremos nuevamente.

Para habilitar el almacenamiento en caché de las respuestas de un servidor proxy, incluya la directiva proxy_cache_path en el contexto de nivel superior http {} . Para especificar cómo se almacenan en caché las solicitudes, también puede agregar la directiva proxy_cache_key de la siguiente 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ón, active la caché en la directiva de ubicación.

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

Para definir las condiciones bajo las cuales NGINX no envía contenido almacenado en caché y no almacena en caché una respuesta del servidor ascendente, incluya proxy_cache_bypass y proxy_no_cache .

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

Ajuste del rendimiento de la caché de proxy

Las siguientes directivas son útiles para ajustar el rendimiento de la caché del proxy. También tienen los mismos significados que las directivas 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;

Para obtener más información y las directivas de configuración de almacenamiento en caché, consulte la documentación de los dos módulos principales ngx_http_fastcgi_module y ngx_http_proxy_module.

Recursos adicionales: almacenamiento en caché de contenido de NGINX y consejos para mejorar el rendimiento de WordPress.