Optimización del Rendimiento de Nginx: Consejos para Sitios Web Más Rápidos

Los sitios lentos generalmente provienen de un puñado de causas: respuestas costosas del upstream, encabezados de caché faltantes, activos sobredimensionados, trabajadores bloqueados o un servidor ajustado para valores predeterminados en lugar de tu tráfico. La optimización del rendimiento de Nginx funciona mejor cuando mides primero, cambias una configuración a la vez y mantienes la configuración legible.

Usa los ejemplos a continuación como puntos de partida, luego pruébalos con carga contra tu propia aplicación. Un servidor de archivos estáticos, un sitio WordPress/PHP-FPM y un proxy inverso de API necesitan diferentes compensaciones.

Comprendiendo los Cuellos de Botella de Rendimiento de Nginx

Comienza por encontrar el cuello de botella. Las causas comunes incluyen:

Uso de CPU: Una alta carga de CPU ralentiza el manejo de solicitudes, la compresión y el trabajo TLS.
Presión de memoria: El intercambio (swapping) perjudica gravemente la latencia.
E/S de red: Enlaces lentos, ventanas upstream pequeñas o pérdida de paquetes pueden dominar el tiempo de respuesta.
E/S de disco: Los archivos estáticos, archivos de caché y registros aún tocan el almacenamiento.
Latencia del upstream: Nginx puede ser rápido mientras tu servidor de aplicaciones es lento.

Herramientas como top, htop, iostat, ss, los registros de acceso y el módulo stub_status de Nginx pueden ayudarte a decidir qué ajustar.

Técnicas Principales de Optimización de Nginx

Procesos de Trabajo y Conexiones

La directiva worker_processes controla cuántos procesos de trabajo inicia Nginx. auto es un valor predeterminado práctico porque Nginx detecta los núcleos de CPU disponibles.

# Establece worker_processes al número de núcleos de CPU
worker_processes auto;

Dentro de cada proceso de trabajo, worker_connections limita cuántas conexiones simultáneas puede abrir ese trabajador. El límite superior aproximado es worker_processes * worker_connections, pero la capacidad real también depende de las conexiones upstream, los límites de archivos abiertos, el comportamiento de keep-alive y los límites del sistema operativo.

# Aumenta worker_connections para sitios de alto tráfico
worker_connections 1024;

Si ves "Demasiados archivos abiertos", aumentar solo worker_connections no es suficiente. También verifica el límite de descriptores de archivo del servicio, a menudo controlado por LimitNOFILE de systemd o los límites del shell.

Estrategias de Caché

El almacenamiento en caché suele ser la optimización de rendimiento de Nginx de mayor impacto porque evita trabajo repetido.

Caché del Navegador

Indica a los navegadores que almacenen en caché activos estáticos versionados como imágenes, CSS y JavaScript. Usa tiempos de vida largos solo cuando los nombres de archivo cambien en el despliegue, como app.8f3c1.css.

location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
    add_header Cache-Control "public";
}

Caché de Proxy

Si Nginx es un proxy inverso, puede almacenar en caché respuestas seleccionadas del backend. Esto funciona bien para páginas públicas, respuestas de API con reglas claras de frescura y páginas costosas que no varían por usuario.

Primero, define una zona de caché en el bloque http:

http {
    # ... otras configuraciones http ...
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;
    # ...
}

/var/cache/nginx: El directorio donde se almacenarán los archivos de caché.
levels=1:2: Define la estructura de directorios para la caché.
keys_zone=my_cache:10m: Crea una zona de memoria compartida llamada my_cache con 10MB de tamaño para almacenar las claves de caché.
max_size=1g: Establece el tamaño máximo de la caché.
inactive=60m: Elimina las entradas de caché que no se hayan accedido durante 60 minutos.

Luego, habilita la caché en tu bloque location:

location / {
    proxy_pass http://tu_app_backend;
    proxy_cache my_cache;
    proxy_cache_valid 200 302 10m; # Almacena en caché respuestas 200 y 302 durante 10 minutos
    proxy_cache_valid 404 1m;     # Almacena en caché respuestas 404 durante 1 minuto
    add_header X-Cache-Status $upstream_cache_status;
}

add_header X-Cache-Status $upstream_cache_status; es útil para depuración, mostrando si una solicitud fue un acierto de caché, un fallo o un bypass.

No almacenes en caché páginas personalizadas a menos que tu clave de caché tenga en cuenta los datos que cambian la respuesta. Por ejemplo, un panel de control con sesión iniciada generalmente debe omitir la caché del proxy, mientras que /assets/logo.png puede almacenarse en caché durante mucho tiempo.

Compresión

La compresión reduce el tamaño de transferencia para respuestas basadas en texto como HTML, CSS, JavaScript, JSON y XML. No ayuda mucho para archivos ya comprimidos como JPEG, PNG, MP4 o muchos formatos de archivo.

http {
    # ...
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    # ...
}

gzip on;: Habilita la compresión Gzip.
gzip_vary on;: Agrega el encabezado Vary: Accept-Encoding, que es importante para los proxies de caché.
gzip_proxied any;: Comprime también las respuestas para solicitudes proxy.
gzip_comp_level 6;: Establece el nivel de compresión (1-9, más alto significa mejor compresión pero más CPU).
gzip_types ...;: Especifica los tipos MIME a comprimir.

Brotli puede comprimir bien los activos de texto, pero las compilaciones estándar de Nginx de código abierto no todas incluyen soporte para Brotli. Verifica tu paquete o conjunto de módulos antes de agregar directivas de Brotli.

Manejo de Conexiones y Keep-Alive

La directiva keepalive_timeout controla cuánto tiempo permanece abierta una conexión de cliente inactiva. Reutilizar una conexión evita handshakes TCP y TLS adicionales, pero las conexiones inactivas aún consumen recursos.

http {
    # ...
    keepalive_timeout 65;
    keepalive_requests 1000;
    # ...
}

keepalive_timeout 65;: Establece el tiempo de espera de keep-alive en 65 segundos.
keepalive_requests 1000;: Establece el número máximo de solicitudes que se pueden realizar sobre una sola conexión keep-alive.

Para APIs con muchas solicitudes cortas, keep-alive ayuda. Para un servidor pequeño con muchos clientes inactivos, un tiempo de espera más corto puede ser mejor.

Límites de Buffering y Tamaño de Solicitud

Nginx usa buffers para los cuerpos de los clientes y las respuestas proxy. Los valores predeterminados son adecuados para muchos sitios, pero las aplicaciones con muchas cargas y los encabezados upstream grandes pueden necesitar configuraciones explícitas.

http {
    # ...
    client_body_buffer_size 10K;
    client_max_body_size 8M;
    proxy_buffers 8 16k;
    proxy_buffer_size 16k;
    proxy_connect_timeout 60;
    proxy_send_timeout 60;
    proxy_read_timeout 60;
    # ...
}

client_body_buffer_size: Tamaño del buffer utilizado para leer el cuerpo de la solicitud del cliente.
client_max_body_size: Tamaño máximo permitido del cuerpo de la solicitud del cliente.
proxy_buffers, proxy_buffer_size: Controlan el buffering cuando Nginx actúa como proxy.

Evita copiar configuraciones de buffer a ciegas. Si ves "upstream sent too big header", investiga los encabezados upstream antes de aumentar proxy_buffer_size. Si las cargas fallan con "413 Request Entity Too Large", establece client_max_body_size al tamaño que tu aplicación realmente soporta.

Optimización TLS

Para sitios HTTPS, la configuración TLS afecta tanto la latencia como la seguridad.

Reanudación de sesión: Usa una caché de sesión para acelerar las conexiones repetidas.
```
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;
```
Versiones TLS: Habilita TLS 1.2 y TLS 1.3 a menos que tus requisitos de compatibilidad digan lo contrario.
OCSP stapling: Puede reducir los viajes de ida y vuelta de validación de certificados cuando tu cadena de certificados lo soporta.
```
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
```

Servicio de Archivos Estáticos

Nginx es fuerte en el servicio de archivos estáticos. Estas directivas son comunes en el bloque http:

sendfile: Permite que el kernel copie datos de archivos directamente al socket en sistemas compatibles.
```
sendfile on;
```
tcp_nopush y tcp_nodelay: Ajustan el comportamiento de envío de paquetes para cargas de trabajo HTTP comunes.
```
tcp_nopush on;
tcp_nodelay on;
```

Monitoreo y Pruebas

Después de cada cambio, prueba y compara. Las herramientas útiles incluyen:

stub_status de Nginx: Conexiones activas, conexiones aceptadas, conexiones manejadas y solicitudes.
top/htop: Presión de CPU y memoria.
iostat: E/S de disco.
WebPageTest o PageSpeed Insights: Rendimiento del lado del navegador.
wrk, ab o hey: Pruebas de carga locales contra endpoints controlados.

Mantén una copia de la configuración anterior, ejecuta sudo nginx -t, recarga y compara latencia, tasa de error, CPU y tiempo de respuesta upstream. La mejor optimización de rendimiento de Nginx es aquella que tus mediciones pueden probar.

Conclusión Práctica

Comienza con la medición, luego soluciona primero el cuello de botella más grande. Para la mayoría de los sitios web, esto significa establecer límites de trabajadores sensatos, agregar caché del navegador para activos estáticos, habilitar gzip, almacenar en caché respuestas upstream seguras y observar los registros después de cada recarga.