Flujo de procesamiento HTTP de Nginx: ajuste de la configuración

La configuración predeterminada de Nginx está diseñada para la compatibilidad, no para el rendimiento. Con un ajuste adecuado, un solo servidor puede gestionar entre 50 000 y 80 000 solicitudes por segundo. Esta guía abarca los ajustes más importantes: procesos de trabajo, conexiones, keepalive, almacenamiento en búfer, equilibrio de carga y cómo verificar los cambios mediante pruebas de rendimiento.

Cómo procesa Nginx las solicitudes HTTP

Nginx gestiona las solicitudes en fases distintas, cada una de las cuales consume recursos del sistema. Comprender el flujo te ayuda a configurar los ajustes adecuados.

Comienza a nivel del núcleo. Las conexiones entrantes llegan a las colas SYN y ACCEPT, y los procesos de trabajo de Nginx las recogen. Una vez aceptadas, el proceso de trabajo analiza la solicitud HTTP desde el búfer del núcleo. El tráfico TLS hace que este paso requiera un mayor uso de la CPU.

A continuación, Nginx empareja la solicitud con un servidor virtual utilizando el encabezado Host y la combinación de IP/puerto, y luego resuelve la URI a un bloque de ubicación mediante la coincidencia de prefijos o expresiones regulares.

Para el contenido dinámico, Nginx reenvía la solicitud a un backend (FastCGI, proxy). Esta fase de comunicación ascendente se beneficia enormemente de las conexiones persistentes. Sin keepalive ascendente, Nginx abre una nueva conexión TCP por cada solicitud, lo que añade latencia y sobrecarga de CPU.

Si proxy_buffering está habilitado, Nginx lee la respuesta completa del servidor de origen en la memoria antes de entregarla al cliente. Esto libera al trabajador para gestionar nuevas solicitudes de inmediato. Por último, durante la entrega de la salida, habilitar sendfile permite transferencias sin copia, lo que puede aumentar el rendimiento de unos 6 Gbps a 30 Gbps.

Cada fase consume búferes de memoria, descriptores de archivo y ciclos de CPU. Las secciones siguientes abordan cada cuello de botella.

Procesos de trabajo y conexiones

Comienza con worker_processes auto; en tu contexto principal. Esto hace coincidir el número de trabajadores con los núcleos de tu CPU. En un VPS con núcleos limitados, establece el número manualmente (p. ej. worker_processes 2;). Si su carga de trabajo consume mucha memoria, considere reducir el número de trabajadores para evitar sobrecargar la RAM.

Habilita worker_cpu_affinity auto; para asignar cada trabajador a un núcleo específico. Esto reduce las faltas de caché y los cambios de contexto. Disponible desde Nginx 1.9.10.

Límites de conexión

La worker_connections directiva establece cuántas conexiones simultáneas puede gestionar cada worker. La capacidad total es worker_processes × worker_connections. El valor predeterminado de 512 o 1.024 es demasiado bajo para entornos de producción. Establezca el valor en 2.048 o 4.096 por trabajador para sitios con mucho tráfico.

Cada conexión necesita al menos un descriptor de archivo. En una configuración de proxy inverso, cada conexión utiliza dos (uno para el cliente y otro para el servidor de origen). Establece worker_rlimit_nofile un valor que sea al menos el doble del worker_connections valor con un margen de seguridad. Para worker_connections 4096;, utilice worker_rlimit_nofile 10000; o superior.

A nivel del sistema, aumente fs.file-max en /etc/sysctl.conf a al menos 500 000 y configura LimitNOFILE=65535.

Por último, añade multi_accept on; en el bloque de eventos para que los trabajadores acepten todas las conexiones pendientes a la vez en lugar de una por una.

Tiempos de espera y Keepalive

Keepalive del cliente

La keepalive_timeout directiva controla cuánto tiempo permanecen abiertas las conexiones de clientes inactivos. Para servidores con mucho tráfico, entre 30 y 65 segundos funciona bien. Utilice la forma de dos parámetros:

keepalive_timeout 65s 60s;

El primer valor es el tiempo de espera del lado del servidor. El segundo envía un Keep-Alive: timeout=60 encabezado al cliente. Establecer el valor del cliente ligeramente por debajo evita condiciones de carrera en las que los navegadores intentan reutilizar conexiones que Nginx ya ha cerrado.

La keepalive_requests directiva limita el número de solicitudes que puede gestionar una sola conexión antes de ser retirada. El valor predeterminado es 1000 (aumentado desde 100 en la versión 1.19.10). Para backends estables, aumente este valor a 10 000 para reducir la rotación de conexiones.

Los tiempos de espera del proxy

proxy_connect_timeout establece cuánto tiempo espera Nginx para establecer una conexión con el backend. El valor predeterminado es 60 segundos. Redúzcalo a entre 5 y 10 segundos para una conmutación por error rápida.

proxy_read_timeout define cuánto tiempo espera Nginx entre lecturas sucesivas del servidor upstream. Ajústelo al tiempo de espera de ejecución de su backend. Si el de PHP-FPM request_terminate_timeout es de 120 segundos, establezca proxy_read_timeout a al menos 120 segundos para evitar errores 504 prematuros.

proxy_send_timeout controla el intervalo entre escrituras sucesivas al servidor upstream. El valor predeterminado de 60 segundos suele ser adecuado, a menos que envíes cuerpos de solicitud de gran tamaño.

Por regla general, proxy_connect_timeout siempre debe ser el más corto de los tres.

Tamaño del búfer

client_body_buffer_size controla la cantidad del cuerpo de una solicitud entrante que Nginx mantiene en memoria. El valor predeterminado de 8k o 16k gestiona envíos de formularios sencillos, pero las subidas de archivos se desbordarán al disco. Auméntalo a 128k para subidas de tamaño pequeño a mediano. Aumenta client_max_body_size el valor predeterminado de 1 MB si los usuarios suben archivos más grandes.

proxy_buffer_size gestiona los encabezados de respuesta por separado del cuerpo. El valor predeterminado de 4k u 8k suele funcionar, pero las aplicaciones con encabezados grandes Set-Cookie (algo habitual en el comercio electrónico) pueden sobrepasarlo, provocando errores 502. Mide el tamaño real de tus encabezados:

curl -s -w '%{size_header}' -o /dev/null http://your-upstream-url

Redondea al incremento de 4k más cercano.

proxy_buffers establece el número y el tamaño de los búferes para el cuerpo de la respuesta. El valor predeterminado (8 búferes de 4k u 8k, con un total de 32k a 64k) no admitirá una respuesta JSON grande. Mide tu respuesta típica más grande con curl y configura suficientes búferes para mantenerla íntegramente en la RAM.

Comportamiento del almacenamiento en búfer del proxy

Con proxy_buffering on (el valor predeterminado), Nginx lee la respuesta completa del servidor de origen en la memoria antes de enviarla al cliente. Esto permite a los servidores backend pasar a nuevas solicitudes inmediatamente.

Establezca proxy_busy_buffers_size a al menos proxy_buffer_size más un búfer, pero menos que el tamaño total de tu pool de búferes. Para proxy_buffers 8 16k (128k en total), mantén proxy_busy_buffers_size por debajo de 112k.

Para puntos finales en tiempo real, como eventos enviados por el servidor o sondeo prolongado, desactive el almacenamiento en búfer proxy_buffering off en un bloque específico de la ubicación. Aplique esto de forma selectiva a /stream o /events , no de forma global.

Equilibrio de carga y keepalive ascendente

Por defecto, Nginx abre una nueva conexión TCP para cada solicitud proxy. Cada handshake añade entre 10 y 100 ms de latencia, y el TLS añade otros 10 a 50 ms. El keepalive de upstream mantiene un conjunto de conexiones persistentes para eliminar esta sobrecarga.

Se requieren tres ajustes:

upstream backend {
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    keepalive 128;
}
 
server {
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

El keepalive establece el número máximo de conexiones inactivas por trabajador. Calcule el tamaño óptimo del grupo de la siguiente manera: (workers × target concurrency) / upstream nodes.

Establece el valor de upstream keepalive_timeout entre 60 y 120 segundos para que coincida con la configuración de su backend y pueda gestionar los picos de tráfico.

Estrategias de equilibrio de carga

Nginx admite varios métodos de equilibrio de carga. Round-robin (el predeterminado) distribuye las solicitudes de forma secuencial. least_conn dirige las solicitudes al servidor con menos conexiones activas, lo que se adapta a cargas de trabajo con duraciones de solicitud variables. ip_hash proporciona persistencia de sesión al enrutar la misma IP de cliente al mismo backend.

Utilice el weight parámetro cuando los servidores tienen capacidades diferentes:

upstream backend {
    least_conn;
    server 10.0.1.10:8080 weight=3;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080 backup;
    keepalive 128;
}

El servidor ponderado recibe el triple de tráfico. El backup servidor solo se activa si todos los servidores principales están inactivos. Configure max_fails y fail_timeout para comprobaciones de estado pasivas, y utiliza max_conns para limitar las conexiones simultáneas por backend.

Pruebas y supervisión

Mida siempre el rendimiento de referencia antes de realizar cualquier cambio. Después de cada cambio, vuelva a realizar una prueba de rendimiento. Realice un cambio cada vez.

Valida la sintaxis de tu configuración con nginx -t antes de recargar. Ejecute las pruebas de rendimiento desde una máquina independiente para evitar la contienda por los recursos.

wrk es la herramienta estándar para pruebas de carga HTTP:

wrk -t4 -c200 -d30s http://your-server.com/

Realice un seguimiento de las solicitudes por segundo, la latencia media, la latencia máxima y la velocidad de transferencia. Apache Bench sirve para pruebas más sencillas:

ab -n 50000 -c 40 http://your-server.com/

Supervisión continua

Habilita el stub_status módulo para supervisar las conexiones activas en tiempo real a través de curl http://localhost/nginx_status.

Añade variables de tiempo a tu formato de registro para identificar dónde se producen los retrasos:

• $request_time para la duración total de la solicitud
• $upstream_connect_time para el tiempo de conexión con el backend
• $upstream_response_time para el tiempo total de procesamiento del backend

Comprueba los registros de errores en busca de problemas de búfer con journalctl -u nginx --no-pager | grep "temporary file". Si las respuestas están llegando al disco, es que proxy_buffers son demasiado pequeños. Busca errores de «demasiados archivos abiertos», que indican worker_rlimit_nofile necesidad de aumentar.

Reduce la E/S de los registros con el registro en búfer:

access_log /var/log/nginx/access.log combined buffer=64k flush=5s;

Utilice ss -tn state established dst [backend_ip] durante las pruebas de carga para verificar que las conexiones se reutilizan y no se acumulan en TIME_WAIT.

Para servidores dedicados y alojamiento VPS optimizados para cargas de trabajo de alto rendimiento, consulta FDC Servers.