Ir al contenido 
Escalo los trabajadores de Nginx de forma específica para gestionar miles de solicitudes simultáneas con un bajo Latencia para su funcionamiento. La clave reside en una combinación equilibrada de worker_processes, worker_connections, descriptores de archivo y Eventos.
Puntos centrales
- Capacidad = worker_processes × worker_connections; en el caso de un proxy inverso, a menudo se trata de la conexión del cliente y la conexión upstream duplicado.
- Descriptores de archivos (worker_rlimit_nofile, ulimit) en función de la carga de conexiones prevista ascensor.
- Eventos-Bloqueo con epoll, multi_accept y colas de espera del núcleo ante una carga elevada recortar.
- Monitoreo mediante stub_status y pruebas de carga para iteraciones Personalización.
- Escala Combinar en vertical y en horizontal, configuración desacoplar.
Arquitectura de NGINX: Master, Worker y eventos
NGINX se basa en un proceso maestro que inicia varios procesos de trabajo y los gestiona de forma eficiente con Eventos se gestiona. En lugar de hilos por solicitud, cada trabajador procesa numerosas conexiones de forma no bloqueante mediante un modelo basado en eventos con un bajo Sobrecarga. Establezco la directiva `worker_processes` en «auto» para que NGINX aproveche los núcleos de la CPU y cada unidad disponga de su propio proceso de trabajo. De este modo, distribuyo mejor las conexiones entrantes y mantengo la latencia bajo control durante los picos de carga. bajo. Para profundizar en la planificación de los procesos, te remito a Optimizar los procesos de los trabajadores, ya que una paralelización correcta determina la capacidad de conexión viable. Es fundamental que el parámetro «worker_connections» se ajuste adecuadamente para cada trabajador, de modo que la multiplicación por el número de procesos dé como resultado el valor esperado Carga máxima cubre.
Fórmula de capacidad: worker_processes × worker_connections
Calculo la capacidad aproximada multiplicando worker_processes por worker_connections, aunque las solicitudes proxy suelen ocupar dos conexiones por cada acceso de usuario, lo que reduce a la mitad el número efectivo. puede. Muchas instalaciones estándar comienzan con 512 conexiones por trabajador, lo que a menudo resulta insuficiente para las cargas de trabajo en producción es. Los valores iniciales más habituales oscilan normalmente entre 1024 y 4096, y dependen del perfil de tráfico y del hardware. Yo calculo con un margen de seguridad, es decir, al menos el doble de la carga máxima medida, para poder gestionar con seguridad los picos de tráfico amortiguar. Sigue siendo importante la validación mediante pruebas y métricas en tiempo real, para que las cifras no se conviertan en un mero juego teórico convertirse en.
| Escenario | procesos_trabajadores | conexiones_trabajadores | Máximo teórico:. | Efectivo (proxy) | FD por trabajador |
|---|---|---|---|---|---|
| Página web pequeña | 2 | 1024 | 2048 | ~1024 | ≥1024 |
| API de carga media | 4 | 2048 | 8192 | ~4096 | ≥2048 |
| Horarios de mayor afluencia en la tienda | 8 | 4096 | 32768 | ~16384 | ≥4096 |
HTTP/1.1, HTTP/2 y TLS: repercusiones en los trabajadores y la latencia
Los protocolos determinan el perfil de conexión. Con HTTP/1.1, suelo observar muchas conexiones TCP simultáneas por cliente, mientras que HTTP/2 las reduce a unos pocos flujos, que, en cambio, están más saturados. paquetes. Esto ahorra descriptores de archivo, pero traslada la carga a los búferes y a la gestión de prioridades. Con TLS, me aseguro de reutilizar las sesiones para que no haya que realizar costosos handshakes en cada solicitud reducir la velocidad. Una caché de sesiones compartida y unos tiempos de espera adecuados reducen los picos de carga de la CPU. Además, no configuro el valor de «keepalive_requests» demasiado bajo, para que las conexiones de larga duración puedan aportar sus ventajas reproducir. Para HTTP/2, calculo una mayor concurrencia por conexión y me aseguro de que los búferes de envío y recepción sean lo suficientemente grandes, sin consumir memoria desperdiciar. En el caso de tráfico mixto, realizo una planificación conservadora y verifico los efectos por variante de protocolo en el Prueba.
Configurar correctamente los descriptores de archivo y ulimit
Cada conexión necesita al menos un descriptor de archivo; en el caso de los proxies inversos, a menudo se necesitan dos, por lo que unos valores bajos de ulimit suponen un gran Límites Configurar. Aumento el valor de `worker_rlimit_nofile` de tal forma que sea posible alcanzar `worker_processes × worker_connections` y que quede margen para los registros, los sockets y las cachés. A nivel de sistema, ajusto los archivos `limits.conf` y `fs.file-max` para que el sistema operativo permita el número previsto de archivos abiertos y no se agote prematuramente frenos. Mediante «ulimit -n» y el parámetro de Systemd (LimitNOFILE), compruebo si la configuración se mantiene y se adapta a NGINX. Quien ignore este ajuste, experimentará, a pesar de un valor elevado de «worker_connections», conexiones rechazadas de forma repentina y un aumento de Latencias.
Ajuste fino del bloque de eventos: epoll, multi_accept, backlogs
En Linux utilizo epoll, ya que este mecanismo gestiona de forma eficiente un gran número de conexiones mediante Eventos gestiona. Con «multi_accept on», un trabajador acepta varias conexiones nuevas por evento, lo que suaviza los picos de carga y reduce los retrasos en la aceptación disminuye. Aumento los parámetros del kernel, como net.core.somaxconn y net.ipv4.tcp_max_syn_backlog, según sea necesario, para evitar que las colas de aceptación se desborden durante las oleadas de tráfico. Las optimizaciones de TIME_WAIT, como tcp_tw_reuse, reducen los cuellos de botella en los puertos y mantienen la curva de rendimiento. alta. Para obtener información más detallada sobre la ejecución en paralelo y las colas, merece la pena echar un vistazo a Optimización del grupo de subprocesos, aunque NGINX funcione principalmente por eventos y, por lo tanto, sea muy eficiente a escala.
Cómo distribuir correctamente los sockets de lista: reuseport, backlog y accept_mutex
Cuando hay muchas conexiones simultáneas, escalo activamente la ruta de recepción. Con reuseport Cada worker recibe su propio socket de escucha; de este modo, se elimina la competencia en la función «accept» y la carga se distribuye de forma equitativa entre todos los núcleos. Establezco explícitamente el «listen-backlog» para absorber picos de tráfico breves. En esta configuración, el `accept_mutex` ya no es necesario. Sin embargo, sin `reuseport`, el `accept_mutex` ayudar, para mitigar los efectos de manada en Accept. Importante: los tamaños de la cola de espera en NGINX y el kernel (somaxconn) deberían encajar, de lo contrario, el efecto se desvanecerá.
events {
use epoll;
worker_connections 4096;
# accept_mutex on; # con reuseport, normalmente no es necesario
}
server {
listen 443 ssl http2 reuseport backlog=65535;
# ...
}
Además, asigno los trabajadores a los núcleos de la CPU cuando es necesario (worker_cpu_affinity), para que las líneas de caché y la carga de IRQ se mantengan estables. En entornos con una fuerte arquitectura NUMA, esto reduce el Tráfico transversal en la memoria.
Proxy inverso, servidores de origen y Keep-Alive
Como proxy inverso, NGINX suele mantener dos conexiones por cada solicitud: una con el cliente y otra con el backend, lo que permite una planificación realista de la capacidad doble es importante. Activo Keep-Alive de forma adecuada para que las conexiones upstream puedan reutilizarse y la sobrecarga por solicitud disminuye. De este modo, reduzco la carga sobre PHP-FPM, el servidor de aplicaciones o los microservicios y consigo ranuras libres para nuevas sesiones de usuario. El equilibrio entre los tiempos de espera, el tiempo de inactividad y la reutilización determina la eficacia con la que se reciclan las conexiones convertirse en. Quien quiera consultar información básica al respecto, la encontrará en Conexiones persistentes Consejos prácticos sobre la utilización de la red y cómo mejorar el rendimiento de la redUtilice.
Grupos de upstream, tiempos de espera y reintentos
Para que los «workers» no tengan que esperar a backends lentos, utilizo tiempos de espera reducidos y reintentos bien dosificados. Mantengo los grupos de «keepalive» de upstream lo suficientemente grandes como para que las conexiones se mantengan activas, pero no tan grandes como para que los descriptores de archivo inactivos ocupen memoria y ranuras vincular. Limito los reintentos a unos pocos intentos y solo cambio de ruta en caso de errores de transporte evidentes; así evito el efecto «thundering herd» ante breves interrupciones del backend.
upstream app_backend {
server 10.0.0.11:8080 max_fails=3 fail_timeout=10s;
server 10.0.0.12:8080 max_fails=3 fail_timeout=10s;
keepalive 64; Conexiones upstream reutilizables #
}
server {
location / {
proxy_pass http://app_backend;
proxy_connect_timeout 2s;
proxy_read_timeout 15s;
proxy_send_timeout 15s;
proxy_next_upstream error timeout http_502 http_503;
proxy_next_upstream_tries 2;
}
}
Al mismo tiempo, ajusto los parámetros de Keep-Alive (tiempos de espera, solicitudes por conexión) para liberar rápidamente los recursos de los clientes que rara vez están activos dar a conocer.
Planificar la escalabilidad de forma adecuada: combinar la escalabilidad vertical y horizontal
Para gestionar grandes volúmenes de tráfico, prefiero combinar el escalado vertical y el horizontal en Considerar. En cuanto a la escalabilidad vertical, utilizo más núcleos de CPU, más RAM, discos SSD rápidos y una configuración de red optimizada para que cada worker funcione con fluidez funciona. Para la escalabilidad horizontal, utilizo nodos NGINX sin estado, una configuración gestionada de forma centralizada y un registro distribuido, de modo que la capacidad total aumente de forma lineal crece. Las cachés locales y las políticas bien definidas a través de Maps o la API permiten implementar los cambios rápidamente. Esta separación reduce los efectos secundarios y ayuda a gestionar nuevos patrones de tráfico sin necesidad de realizar modificaciones en cada nodo. servir.
Perspectiva del alojamiento web: latencia, índices de error y experiencia del usuario
Un número insuficiente de «worker_connections» provoca que se rechacen conexiones, se produzcan tiempos de espera y un peor Experiencia del usuario. Las aplicaciones dinámicas, como los CMS o las tiendas online, lo notan de inmediato, ya que cada visita a una página genera varias solicitudes al backend y los slots se agotan más rápido corto Por eso empiezo con valores moderados, como 1024 o 2048 por trabajador, y los voy aumentando gradualmente basándome en mediciones reales. Al mismo tiempo, mantengo el rendimiento de los servicios de origen y me aseguro de que haya suficientes descriptores de archivo para que no se produzcan Límites aplicar. Las pruebas de rendimiento demuestran que las plataformas cuidadosamente optimizadas ofrecen ventajas reales en este ámbito y gestionan de forma fiable los picos de tráfico interceptar.
Memoria, almacenamiento en búfer y rutas de E/S
Cada conexión ocupa memoria RAM para metadatos y búferes. Ajusto los valores de `proxy_buffers`, `client_body_buffer_size` y `large_client_header_buffers` de manera que quepan las solicitudes típicas, sin destinar de forma generalizada demasiada RAM a los casos atípicos. vincular. En el caso de los contenidos estáticos, «sendfile» y «tcp_nopush» aceleran la entrega, mientras que «tcp_nodelay» es adecuado para respuestas breves en las que la latencia es un factor crítico Importante . Si los activos se encuentran en un almacenamiento más lento, «aio threads» junto con «thread_pool» ayudan a mitigar los efectos de bloqueo. Con «open_file_cache» reduzco los accesos a los archivos y las llamadas a «stat()», pero hay que tener en cuenta la necesidad adicional de descriptores de archivo (FD). Guardo los registros en búfer (access_log … buffer=… flush=…), para que los picos de E/S no afecten a los tiempos de respuesta influir.
Equilibrio entre seguridad y rendimiento de TLS
Los handshakes TLS consumen muchos recursos de la CPU. Combino la reutilización de sesiones con parámetros de clave moderados y activo optimizaciones acumulables, como cachés de sesión y tickets, siempre que sea viable desde el punto de vista operativo ajuste. El equilibrio óptimo entre seguridad y rendimiento mantiene estables las latencias sin sacrificar la calidad del cifrado. Bajo una carga más elevada, observo por separado los percentiles 95 y 99, ya que, de lo contrario, los picos de TLS quedarían ocultos tras los valores medios ocultar. HTTP/2 reduce el número de conexiones, pero exige un tratamiento cuidadoso del control de flujo y la compresión de encabezados para mantener bajo control los perfiles de CPU y memoria conservar.
Resiliencia ante la sobrecarga: límites y liberación gradual
Para mantener la latencia, es necesario realizar una Modelado Imprescindible en momentos de máxima carga. Con «limit_conn» limito el número de conexiones paralelas por clave (por ejemplo, IP o sesión), mientras que «limit_req» modera las picos de carga y protege los backends frente a las operaciones síncronas Asaltar. Aíslo los puntos críticos con reglas más estrictas que los recursos estáticos. Si se produce un pico de carga a corto plazo, devuelvo códigos de error 429/503 bien definidos con «Retry-After», en lugar de distribuir todas las solicitudes de manera uniforme morir de hambre Dejar que se mantengan. Detengo las conexiones persistentes (lingering_close) para liberar recursos de forma controlada y evitar patrones de tipo Slowloris. refutar. Este «shedding» activo mantiene la latencia p95/p99 dentro de los límites aceptables, incluso cuando la demanda total supera temporalmente la capacidad nominal mentiras.
Integración de contenedores y sistemas: eliminar las limitaciones allí donde surgen
En los contenedores suelen aplicarse límites más estrictos. Compruebo los límites de cgroup (CPU, RAM), configuro ulimit -n adecuadamente dentro del contenedor e incorporo LimitNOFILE en la definición del servicio. Los parámetros de sysctl como somaxconn y tcp_max_syn_backlog deben establecerse en el Anfitrión entren en vigor; los espacios de nombres no siempre aíslan estos ajustes de forma transparente. En plataformas orquestadas, planifico la capacidad por pod/nodo, asigno los trabajadores a los núcleos asignados y me aseguro de que las rutas de red sean estables (por ejemplo, sin saltos NAT innecesarios), para que la curva de latencia tranquilo permanece. Acompaño las actualizaciones continuas con worker_shutdown_timeout para que las conexiones existentes se cierren correctamente agotarse.
Seguimiento y optimización iterativa
Sin visibilidad, las medidas de ajuste siguen siendo Riesgo. Activo «stub_status» u otras alternativas para supervisar de forma continua las conexiones activas, las tasas de aceptación y los rechazos. En las pruebas de carga, simulo patrones de acceso realistas e identifico cuellos de botella en las colas de aceptación, las latencias de upstream o la CPU-Saturación. A continuación, ajusto con cuidado el número de conexiones de los trabajadores, los procesos, los límites de archivos y los parámetros TCP, y vuelvo a comprobar el resultado. Este ciclo garantiza la fiabilidad de la plataforma y evita sorpresas en momentos inoportunos Times.
Configuración de ejemplo y proceso de cálculo
Supongamos que espero 2000 solicitudes simultáneas en curso durante las horas punta y utilizo un proxy inverso; en ese caso, calculo aproximadamente 4000 ranuras de conexión más Tampón. Si NGINX se ejecuta en cuatro núcleos de CPU, suelo empezar con `worker_processes auto` y entre 1000 y 2000 conexiones por trabajador. Establezco el límite de descriptores de archivo por trabajador a un valor lo suficientemente alto como para que las conexiones, los registros y los sockets internos tengan suficiente Lugar tengo. Configuro el bloque de eventos en epoll, activo multi_accept y aumento los backlogs del kernel en función de mi tráfico máximo. Un fragmento minimalista podría tener este aspecto, que luego ajusto con pruebas de rendimiento Vote:
worker_processes auto;
worker_rlimit_nofile 65535;
events {
use epoll;
worker_connections 2048;
multi_accept on;
}
http {
keepalive_timeout 65;
sendfile on;
# otras opciones de proxy/caché...
}
Además, añado optimizaciones de listas y de upstream para perfeccionar la ruta de recepción y la ruta de backend bajo carga:
events {
use epoll;
worker_connections 4096;
# worker_cpu_affinity auto; # asignar núcleos fijos si es necesario
}
http {
# Optimizaciones de TLS y sesión a modo de ejemplo
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1h;
upstream app_backend {
server 10.0.0.11:8080;
server 10.0.0.12:8080;
keepalive 64;
}
servidor {
escuchar 443 ssl http2 reutilizar puerto backlog=65535;
ubicación / {
proxy_pass http://app_backend;
proxy_connect_timeout 2s;
proxy_read_timeout 15s;
proxy_next_upstream error timeout http_502 http_503;
proxy_next_upstream_tries 2;
}
}
}
En resumen: valores orientativos concretos
Ajusto el valor de `worker_processes` en función de los núcleos de la CPU y, por lo general, configuro `worker_connections` entre 1024 y 4096. En el caso del proxy inverso, preveo dos conexiones por solicitud y mantengo un margen de al menos el doble del pico medido—Carga. Establezco los valores de `worker_rlimit_nofile` y los límites del sistema a un nivel lo suficientemente alto como para que las cifras del archivo `nginx.conf` sigan siendo realmente útiles. Ajusto el bloque `events` a `epoll` y `multi_accept`, mientras que los backlogs del kernel gestionan breves picos de tráfico amortiguar. Mediante el seguimiento y los ajustes progresivos, consigo crear un motor de tráfico fiable que gestiona de forma ordenada el creciente número de visitas lleva.
