{"id":20714,"date":"2026-08-16T18:19:23","date_gmt":"2026-08-16T16:19:23","guid":{"rendered":"https:\/\/webhosting.de\/nginx-worker-processes-optimal-konfigurieren-performanceboost\/"},"modified":"2026-08-16T18:19:23","modified_gmt":"2026-08-16T16:19:23","slug":"configuracion-optima-de-los-procesos-de-trabajo-de-nginx-para-mejorar-el-rendimiento","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/nginx-worker-processes-optimal-konfigurieren-performanceboost\/","title":{"rendered":"Configurar de forma \u00f3ptima los procesos de trabajo de NGINX para obtener el m\u00e1ximo rendimiento"},"content":{"rendered":"<p>Configuro <strong>NGINX Worker<\/strong> de tal forma que worker_processes, worker_connections y worker_rlimit_nofile coincidan exactamente y Epoll funcione en el bucle de eventos. De este modo, utilizo <strong>N\u00facleos de CPU<\/strong> Eficiente, permite escalar de forma planificada las conexiones simult\u00e1neas y mantiene bajas las latencias en los picos de carga.<\/p>\n\n<h2>Puntos centrales<\/h2>\n<p>Los siguientes aspectos fundamentales te servir\u00e1n de gu\u00eda inmediata para configurar un worker de NGINX resistente.<\/p>\n<ul>\n  <li><strong>procesos_trabajadores<\/strong> vincularlo al n\u00famero de n\u00facleos l\u00f3gicos, idealmente con \u201eauto\u201c.<\/li>\n  <li><strong>conexiones_trabajadores<\/strong> ajustarlo de manera que se cubran holgadamente los picos reales.<\/li>\n  <li><strong>rlimit_nofile<\/strong> y aumentar los l\u00edmites del sistema operativo en funci\u00f3n del volumen de tr\u00e1fico.<\/li>\n  <li><strong>epoll<\/strong> y activar multi_accept para aprovechar de forma eficiente el bucle de eventos.<\/li>\n  <li><strong>Pruebas de carga<\/strong> avanzar y realizar peque\u00f1os ajustes.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-optimierung-serverraum-5961.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Arquitectura de NGINX: entender los servidores \u00abmaster\u00bb y \u00abworker\u00bb<\/h2>\n<p>Separo las tareas de <strong>Maestro<\/strong> Y los \u00abworker\u00bb lo tienen claro: el \u00abmaster\u00bb carga las configuraciones, abre sockets e inicia procesos, mientras que los \u00abworker\u00bb procesan las solicitudes en el bucle de eventos. Cada \u00abworker\u00bb funciona de forma aut\u00f3noma, reacciona a los eventos y puede gestionar miles de conexiones sin generar bloqueos. Este modelo da lo mejor de s\u00ed cuando asigno adecuadamente los n\u00facleos de la CPU y aprovecho al m\u00e1ximo el bucle de eventos mediante epoll. Tengo en cuenta que cada salto de proxy adicional consume recursos de conexi\u00f3n, lo que se refleja en los l\u00edmites. Quien comprenda estas funciones, tomar\u00e1 decisiones conscientes sobre <strong>Recursos<\/strong> y evita los cuellos de botella de forma precoz.<\/p>\n\n<h2>Combinar correctamente las tres directrices clave<\/h2>\n<p>Considero que <strong>procesos_trabajadores<\/strong>, worker_connections y worker_rlimit_nofile nunca se ajustan de forma aislada, sino como un todo. El n\u00famero total de conexiones posibles se calcula multiplicando el n\u00famero de trabajadores por el n\u00famero de conexiones por trabajador; a partir de ah\u00ed deduzco los l\u00edmites para los descriptores de archivo. Si estos par\u00e1metros no est\u00e1n bien ajustados, me encuentro con el error \u201etoo many open files\u201c o sufro tiempos de espera excesivos. Para cargas elevadas necesito una cadena coherente: suficientes procesos, un n\u00famero generoso de conexiones, un valor de rlimit_nofile adecuadamente aumentado y los par\u00e1metros adecuados del sistema operativo. As\u00ed evito que un valor demasiado peque\u00f1o <strong>L\u00edmite<\/strong> ha mermado toda la capacidad.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_worker_meeting_3021.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>worker_processes: Seleccionar el n\u00famero adecuado<\/h2>\n<p>He puesto <strong>procesos_trabajadores<\/strong> Por lo general, se configura en \u201eauto\u201c, para que NGINX detecte el n\u00famero de n\u00facleos l\u00f3gicos de la CPU y pueda aprovechar cada uno de ellos. Un trabajador por n\u00facleo evita cambios de contexto innecesarios y distribuye la carga de forma \u00f3ptima, lo que permite predecir el tiempo de respuesta. En m\u00e1quinas con un gran n\u00famero de n\u00facleos, pruebo deliberadamente con un n\u00famero menor de trabajadores para comparar las aciertos de cach\u00e9 y la utilizaci\u00f3n de los n\u00facleos. Si las m\u00e9tricas indican que los n\u00facleos est\u00e1n sobrecargados o que aumentan las faltas de TLB, ajusto el n\u00famero de trabajadores de forma gradual. Primero medir, luego cambiar: as\u00ed me aseguro unos resultados fiables <strong>Resultados<\/strong>.<\/p>\n\n<h2>worker_connections: aumentar las conexiones de forma planificada<\/h2>\n<p>Elijo el <strong>conexiones_trabajadores<\/strong> Depende del tr\u00e1fico de destino y de la combinaci\u00f3n de protocolos; suele partir de 2048 o 4096. Para las API con mucho tr\u00e1fico, considero la opci\u00f3n de 8192, siempre que los l\u00edmites del sistema operativo y la memoria RAM lo permitan. Compruebo cada aumento con pruebas de carga, ya que las conexiones abiertas consumen memoria e influyen en el comportamiento del servidor de origen. Cuando predominan los handshakes SSL o las subidas de gran volumen, me baso m\u00e1s en los perfiles de CPU y E\/S, y no solo en las cifras puras de conexiones. De este modo, me aseguro de que el n\u00famero definido por trabajador <strong>Capacidad<\/strong> y que siga siendo realmente \u00fatil.<\/p>\n\n<h2>Sincronizar \u00abworker_rlimit_nofile\u00bb y los l\u00edmites del sistema operativo<\/h2>\n<p>Me encargo de que <strong>rlimit_nofile<\/strong> que cubra, como m\u00ednimo, la capacidad total te\u00f3rica y que, a menudo, se configure con un margen de reserva. Para escenarios de proxy inverso, calculo un segundo descriptor por conexi\u00f3n de cliente hacia el servidor de origen. En consecuencia, suelo establecer rlimit_nofile al doble del n\u00famero de conexiones simult\u00e1neas previstas. Aumento los l\u00edmites del n\u00facleo y del usuario (ulimit -n, fs.file-max) de tal forma que NGINX pueda realmente alcanzar esos valores. Si aparecen mensajes sobre archivos abiertos en el registro de errores, los aumento r\u00e1pidamente y observo la <strong>Latencia<\/strong> de nuevo bajo carga.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-performance-optimization-5123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bloque de eventos: c\u00f3mo utilizar eficazmente epoll y multi_accept<\/h2>\n<p>Activo en el bloque de eventos <strong>epoll<\/strong> y configuro \u201emulti_accept\u201c en \u00abon\u00bb para que los trabajadores acepten las conexiones en espera de una sola vez. Epoll reduce la sobrecarga cuando hay muchos sockets simult\u00e1neos y se adapta perfectamente al dise\u00f1o no bloqueante de NGINX. Estos par\u00e1metros resultan muy \u00fatiles en picos de tr\u00e1fico, ya que aceleran la fase de aceptaci\u00f3n y permiten pasar m\u00e1s r\u00e1pidamente al procesamiento propiamente dicho. En Linux, esta es mi configuraci\u00f3n predeterminada, que solo modifico en contadas ocasiones especiales. Quien desee profundizar en el tema, puede comparar el modelo de bucle de eventos con <a href=\"https:\/\/webhosting.de\/es\/threadpool-servidor-web-apache-nginx-litespeed-optimizacion-configuracion\/\">Threadpool frente a bucle de eventos<\/a> y de ah\u00ed deduce <strong>conclusiones<\/strong> para el propio entorno.<\/p>\n\n<h2>Afinidad de la CPU: asignar los trabajadores a los n\u00facleos<\/h2>\n<p>He puesto <strong>afiliaci\u00f3n de trabajadores a la CPU<\/strong> de forma espec\u00edfica cuando las cargas de trabajo son constantes y dependen de la CPU. Distribuyo el esquema de asignaci\u00f3n mediante m\u00e1scaras de bits para evitar cambios de contexto y favorecer la localidad de la cach\u00e9. Con cuatro n\u00facleos, asigno las m\u00e1scaras de tal forma que cada trabajador disponga de su propio n\u00facleo. A continuaci\u00f3n, compruebo las tasas de fallos de cach\u00e9, las latencias medianas y los percentiles del 99 % para observar claramente el efecto. Encontrar\u00e1s explicaciones m\u00e1s detalladas sobre la afinidad y NUMA de forma concisa en <a href=\"https:\/\/webhosting.de\/es\/servidor-proceso-afinidad-numa-sensibilizacion-alojamiento-ressourcentuning\/\">Aplicaci\u00f3n pr\u00e1ctica de la afinidad de la CPU<\/a>, lo cual resulta \u00fatil a la hora de ajustar con precisi\u00f3n <strong>Trabajador<\/strong>-Ayuda con los dise\u00f1os.<\/p>\n\n<h2>Planificaci\u00f3n de la capacidad: margen de seguridad y pruebas de carga<\/h2>\n<p>Cuando se trata de conexiones, tengo pensado hacer una <strong>Tamp\u00f3n<\/strong> que est\u00e9 claramente por encima de los picos observados, para que los picos moment\u00e1neos no superen directamente los l\u00edmites. Si duplico la carga m\u00e1xima como punto de partida, dispongo de un margen de seguridad s\u00f3lido en muchos escenarios. Si el tr\u00e1fico fluct\u00faa mucho, ampl\u00edo a\u00fan m\u00e1s el margen de seguridad hasta que los percentiles del 99 se mantengan estables. A continuaci\u00f3n, compruebo los cuellos de botella con herramientas como wrk o k6, observo las tasas de error y reviso las conexiones activas en el estado. Solo cuando las m\u00e9tricas son consistentes, aumento o reduzco de forma espec\u00edfica cada uno de los <strong>Valores<\/strong>.<\/p>\n\n<h2>Configuraci\u00f3n y ejemplos de c\u00e1lculo<\/h2>\n<p>Calculo la capacidad de conexi\u00f3n multiplicando el n\u00famero de trabajadores por el n\u00famero de conexiones por trabajador y, a partir de ah\u00ed, establezco unos l\u00edmites m\u00e1s altos. Con cuatro n\u00facleos de CPU, el modo \u00abauto\u00bb y 4096 conexiones por trabajador, el c\u00e1lculo me da un resultado de 16 384 conexiones simult\u00e1neas. En escenarios de proxy, suelo establecer rlimit_nofile en 32 768 o m\u00e1s, para que se incluyan los sockets de upstream. En el caso de m\u00e1quinas peque\u00f1as con dos n\u00facleos, suelen bastar 2048 conexiones por trabajador, siempre que el porcentaje de subidas y de TLS se mantenga moderado. La siguiente tabla ayuda a clasificar los <strong>Valores iniciales<\/strong>:<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>N\u00facleos de CPU<\/th>\n      <th>procesos_trabajadores<\/th>\n      <th>worker_connections (Inicio)<\/th>\n      <th>rlimit_nofile m\u00ednimo (valor orientativo)<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>2<\/td>\n      <td>auto (\u22482)<\/td>\n      <td>2048<\/td>\n      <td>\u2265 4096<\/td>\n      <td><strong>Reserva<\/strong> Programar para TLS\/proxy<\/td>\n    <\/tr>\n    <tr>\n      <td>4<\/td>\n      <td>auto (\u22484)<\/td>\n      <td>4096<\/td>\n      <td>\u2265 16 384<\/td>\n      <td>En el caso de los proxies, suele ser un factor de 2 en los FD<\/td>\n    <\/tr>\n    <tr>\n      <td>8<\/td>\n      <td>auto (\u22488)<\/td>\n      <td>4096-8192<\/td>\n      <td>\u2265 32 768<\/td>\n      <td><strong>Prueba de carga<\/strong> decide sobre el aumento<\/td>\n    <\/tr>\n    <tr>\n      <td>16+<\/td>\n      <td>coche, o menos, si procede<\/td>\n      <td>8192+<\/td>\n      <td>\u2265 65 535<\/td>\n      <td>Probar con afinidad y discreci\u00f3n<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_performance_opt_4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NGINX Worker y Upstreams: c\u00f3mo ponderar correctamente los escenarios<\/h2>\n<p>Distingo entre la entrega est\u00e1tica, el funcionamiento del proxy inverso y la carga de la pasarela de API, ya que son los <strong>Trabajador<\/strong>-Configuraci\u00f3n diferente seg\u00fan el caso. Los contenidos est\u00e1ticos consumen menos recursos, mientras que el TLS, la compresi\u00f3n y las conexiones upstream suponen una mayor carga para la CPU y los FD. Cuanto m\u00e1s grandes sean las claves SSL y m\u00e1s handshakes haya, m\u00e1s se beneficia la configuraci\u00f3n \u201eun worker por n\u00facleo\u201c. Las subidas de gran tama\u00f1o desplazan el perfil hacia la E\/S, por lo que me centro m\u00e1s en rlimit_nofile y en los b\u00faferes de red. Cuando se producen tiempos de espera apreciables en la aceptaci\u00f3n o en las respuestas del backend, me resulta \u00fatil tener una visi\u00f3n general de <a href=\"https:\/\/webhosting.de\/es\/servidor-web-cola-latencia-gestion-de-solicitudes-cola-del-servidor\/\">Colas y latencia<\/a>, para evitar los puntos de estrangulamiento <strong>objetivo<\/strong> Resolver.<\/p>\n\n<h2>Flujo de trabajo pr\u00e1ctico: paso a paso hacia un servidor m\u00e1s r\u00e1pido<\/h2>\n<p>Empezar\u00e9 por hacer un an\u00e1lisis de la situaci\u00f3n actual de todos los aspectos relevantes <strong>Valores<\/strong> En el archivo nginx.conf, compruebo los n\u00facleos de la CPU, el ulimit y los par\u00e1metros del kernel. A continuaci\u00f3n, configuro worker_processes en \u00abauto\u00bb, establezco worker_connections, por ejemplo, en 4096 y aumento generosamente el valor de rlimit_nofile. En el bloque \u00abevents\u00bb, activo epoll y multi_accept, y compruebo los registros con una recarga. A continuaci\u00f3n, realizo pruebas de carga en condiciones reproducibles, en las que observo los tiempos de respuesta, las tasas de error y las conexiones abiertas. En el ajuste fino, siempre modifico solo una variable, documento cada paso y compruebo los efectos en los <strong>M\u00e9tricas<\/strong>.<\/p>\n\n<h2>Entorno de alojamiento: recursos, kernel, red<\/h2>\n<p>Me aseguro de que haya suficiente <strong>CPU<\/strong>-N\u00facleos, suficiente RAM, unidades SSD o NVMe r\u00e1pidas y un kernel de Linux actualizado. Solo as\u00ed funcionan de forma fiable epoll, las pilas TCP modernas y las funciones de descarga de carga adecuadas. Ajusto los par\u00e1metros de red, como somaxconn y tcp_max_syn_backlog, al n\u00famero deseado de conexiones para mantener cortas las colas de recepci\u00f3n. Un proveedor con un rendimiento de E\/S s\u00f3lido y una configuraci\u00f3n del sistema de libre acceso resulta claramente ventajoso en este sentido. Las comparativas muestran que los servicios con <strong>Recursos<\/strong> Aumentar considerablemente los m\u00e1rgenes de NGINX.<\/p>\n\n<h2>Estrategia de keepalive: conexiones de cliente y de upstream<\/h2>\n<p>Utilizo Keepalive de forma deliberada como herramienta para gestionar la capacidad y la latencia. En el lado del cliente, configuro <strong>tiempo de espera de keepalive<\/strong> No demasiado alto, para que los sockets inactivos no se <em>conexiones_trabajadores<\/em> bloquear. Los valores entre 10 y 30 s suelen ofrecerme un buen equilibrio entre la reutilizaci\u00f3n y la ocupaci\u00f3n de recursos. Con <strong>keepalive_requests<\/strong> Limito el n\u00famero de solicitudes por conexi\u00f3n para cortar las conexiones prolongadas y evitar la sobrecarga de memoria. En el lado de origen (proxy inverso), mantengo conexiones persistentes con <strong>keepalive<\/strong> en el bloque \u00abupstream\u00bb, de modo que se prescinde de los handshakes y de la configuraci\u00f3n de TCP. Para ello, ajusto el n\u00famero por backend de forma conservadora en funci\u00f3n de la capacidad del backend (<em>max_conns<\/em>), de lo contrario, yo mismo genero colas en el upstream. Importante: cada socket de keepalive cuenta como una conexi\u00f3n abierta y necesita FD; lo tengo en cuenta en <em>rlimit_nofile<\/em> y mi planificaci\u00f3n del margen de maniobra.<\/p>\n\n<h2>Optimizaci\u00f3n de listas: reuseport, backlog y estrategia de aceptaci\u00f3n<\/h2>\n<p>Distribuyo la carga de admisi\u00f3n de manera uniforme haciendo que <strong>SO_REUSEPORT<\/strong> activar (listen \u2026 reuseport). De este modo, cada worker dispone de su propia cola de aceptaci\u00f3n, lo que reduce los \u201ethundering herds\u201c y evita los puntos de congesti\u00f3n. En combinaci\u00f3n con <strong>multi_accept<\/strong> acelero notablemente la fase de aceptaci\u00f3n. La lista de...<strong>retraso<\/strong> (listen \u2026 backlog=) y sus equivalentes en el n\u00facleo (somaxconn, tcp_max_syn_backlog) los configuro con un valor generoso para que los picos no se pierdan en la entrada del socket. La opci\u00f3n <strong>aplazado<\/strong> Aplaza la respuesta \u00abAccept\u00bb hasta que se disponga de los datos; en el caso de muchas solicitudes de corta duraci\u00f3n, esto puede resultar \u00fatil; en los dem\u00e1s casos, lo comparo en las pruebas. Si yo <strong>accept_mutex<\/strong> Lo aclaro en la prueba comparativa: con reuseport, suele ser prescindible; sin reuseport, puede mejorar la equidad, pero requiere coordinaci\u00f3n. En este caso, tomo la decisi\u00f3n bas\u00e1ndome en los datos, nunca por intuici\u00f3n.<\/p>\n\n<h2>Configurar los tiempos de espera y las colas de forma estable<\/h2>\n<p>He puesto <strong>Tiempos muertos<\/strong> de manera que los clientes lentos no saturen los trabajadores: <em>tiempo de espera del encabezado del cliente<\/em> y <em>client_body_timeout<\/em> Lo mantengo lo suficientemente conciso como para evitar atascos, pero lo suficientemente amplio para los usuarios reales. <em>send_timeout<\/em> evita que se bloqueen las respuestas dirigidas al cliente. En el contexto del proxy, defino <em>proxy_connect_timeout<\/em>, <em>proxy_read_timeout<\/em> y <em>proxy_send_timeout<\/em> de forma rigurosa, para que los backends que se cuelgan no paralicen el frontend. En el caso de backends con un paralelismo limitado, utilizo <strong>cola<\/strong> en el bloque \u00abupstream\u00bb con un tiempo de espera, para amortiguar los picos y enviar el c\u00f3digo de error 503 de forma controlada, en lugar de vincular a todos los trabajadores a los sockets de upstream en espera. Adem\u00e1s, estabilizo el sistema con <strong>limit_req<\/strong> (Burst\/Delay) y <strong>limit_conn<\/strong> rutas sensibles, de modo que los clientes o bots individuales no consuman recursos de forma desproporcionada.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_worker_performance_8392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Buffering, sendfile y AIO: elegir deliberadamente los m\u00e9todos de E\/S<\/h2>\n<p>He puesto <strong>sendfile<\/strong> para archivos est\u00e1ticos y comb\u00ednalo con <em>tcp_nopush<\/em>\/<em>tcp_nodelay<\/em> dependiendo de la carga de trabajo, para agrupar paquetes de forma eficiente o reducir las latencias interactivas. Para archivos grandes, utilizo <strong>directio<\/strong> a partir de un umbral determinado, para evitar la contaminaci\u00f3n de la cach\u00e9 y que no se sustituya la cach\u00e9 de p\u00e1ginas. En el modo proxy, decido si <strong>proxy_buffering<\/strong> ayuda (entrega r\u00e1pida al cliente, lectura upstream desacoplada) o si, en caso de cargas de streaming, es mejor que <em>proxy_request_buffering<\/em> Reduzco para iniciar las subidas con antelaci\u00f3n. Los tama\u00f1os de <em>proxy_buffers<\/em>, <em>proxy_buffer_size<\/em> y <em>buffers_de_encabezado_de_cliente_grandes<\/em> Lo controlo de forma deliberada para que el consumo de memoria por conexi\u00f3n no se dispare. Para que el acceso a los archivos no sobrecargue la CPU, estoy considerando <strong>aio<\/strong> (nativo o con subprocesos), pero haz pruebas exhaustivas, ya que las caracter\u00edsticas del bucle de eventos y de E\/S se influyen mutuamente.<\/p>\n\n<h2>HTTP\/2, HTTP\/3 y TLS: repercusiones en la capacidad de los trabajadores<\/h2>\n<p>Tengo en cuenta que <strong>HTTP\/2<\/strong> y <strong>HTTP\/3<\/strong> Modificar la din\u00e1mica de las conexiones: muchas solicitudes se ejecutan como <em>Transmisiones<\/em> a trav\u00e9s de un n\u00famero reducido de conexiones TCP o QUIC. Esto reduce el n\u00famero de conexiones, pero aumenta los requisitos de CPU y memoria por conexi\u00f3n (multiplexaci\u00f3n, compresi\u00f3n de encabezados, TLS\/QUIC). Mi <em>conexiones_trabajadores<\/em> Por eso no lo interpreto a ciegas como \u201eel mismo n\u00famero de solicitudes\u201c. Observo <em>flujos concurrentes<\/em> por conexi\u00f3n y pase <em>tiempo de espera de keepalive<\/em> y, si procede,. <em>http2_max_concurrent_streams<\/em> . Por el lado de TLS, salgo ganando con la reanudaci\u00f3n de sesi\u00f3n (tickets\/cach\u00e9) y el OCSP stapling; as\u00ed me ahorro costosos handshakes y mantengo bajas las latencias. La otra cara de la moneda: los keepalives m\u00e1s largos consumen FD y RAM, as\u00ed que planeo <em>rlimit_nofile<\/em> y cuotas de memoria con reservas realistas. Para los algoritmos de cifrado que exigen un uso intensivo de la CPU, merece la pena probar la afinidad y la aceleraci\u00f3n criptogr\u00e1fica moderna.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-optimaler-setup-9182.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Visibilidad: estado, registros y m\u00e9tricas<\/h2>\n<p>Consigo transparencia con un enfoque \u00e1gil <strong>Estado<\/strong>-Endpoint (por ejemplo, stub_status), para ver las conexiones activas, los estados de lectura, escritura y espera, as\u00ed como las solicitudes aceptadas. En los registros, procuro que haya poco ruido: un registro compacto <em>log_format<\/em> Con la hora, el estado, los tiempos de upstream y los bytes es suficiente para la mayor\u00eda de los an\u00e1lisis. Cuando el QPS es muy alto, desactivo el registro de acceso de forma selectiva (en funci\u00f3n de la ubicaci\u00f3n) o almaceno los registros en b\u00fafer de forma as\u00edncrona, para que las operaciones de E\/S no ralenticen el sistema. El registro de errores lo configuro en <em>avise a<\/em> o <em>error<\/em> y cambia temporalmente a <em>depurar<\/em>. De forma continua, correlaciono las latencias (mediana\/percentil 95\/99), las conexiones abiertas, las tasas de error del backend y la carga de la CPU por trabajador; a partir de ah\u00ed, deduzco los ajustes que hay que aplicar a las tres directivas clave y detecto a tiempo los efectos de saturaci\u00f3n.<\/p>\n\n<h2>Contenedores y entornos virtuales: pasar los l\u00edmites de forma clara<\/h2>\n<p>Compruebo en contenedores la <strong>cgroup<\/strong>-Establece los l\u00edmites para la CPU, la RAM y los PID, y comp\u00e1ralos con la configuraci\u00f3n de NGINX. <em>ulimit -n<\/em> debe ser lo suficientemente alto dentro del contenedor; de lo contrario, mis ajustes de rlimit_nofile no surtir\u00e1n efecto. En el caso de las cuotas de CPU (por ejemplo, 2 vCPU), configuro <em>procesos_trabajadores<\/em> En consecuencia, para que la programaci\u00f3n no se acelere de forma artificial. En lo que respecta a la red, en los modos de red \u201ehost\u201c me beneficio de una menor latencia de sobrecarga, mientras que las superposiciones suponen saltos adicionales. En hosts Multi-NUMA, presto atenci\u00f3n a la afinidad y a los z\u00f3calos de memoria, para que los trabajadores no operen a trav\u00e9s de distintos nodos. Lo mismo se aplica a la afinidad de IRQ y RPS\/XPS: si las rutas desde la NIC, pasando por la IRQ, hasta el n\u00facleo del trabajador son correctas, los picos de latencia se reducen de forma apreciable.<\/p>\n\n<h2>Ciclo de vida de una conexi\u00f3n: puertos ef\u00edmeros, TIME_WAIT y reservas<\/h2>\n<p>Tengo pensado llevar suficiente <strong>Puertos ef\u00edmeros<\/strong> (ip_local_port_range), cuando NGINX act\u00faa como cliente activo frente a los servidores upstream. Cuando el rendimiento de las conexiones es muy alto, evito una fluctuaci\u00f3n excesiva de los puertos mediante el \u201eupstream-keepalive\u201c, lo que reduce las colas TIME_WAIT. Utilizo con cautela los ajustes del kernel relacionados con la \u00abreutilizaci\u00f3n\u00bb; las pilas modernas ya optimizan muchos aspectos internamente. Es m\u00e1s estable controlar la duraci\u00f3n de las conexiones mediante valores adecuados de keepalive y timeout, y <em>reuseport<\/em> para garantizar una distribuci\u00f3n equitativa. En el c\u00e1lculo de la capacidad, adem\u00e1s de los clientes, siempre tengo en cuenta el lado \u00abupstream\u00bb; a menudo, son los FD los que constituyen el verdadero factor limitante, y no la \u00abpuerta de entrada\u00bb.<\/p>\n\n<h2>Recargas y despliegues fluidos sin interrupciones<\/h2>\n<p>Utilizo el modelo maestro\/esclavo para <strong>recargas fluidas<\/strong>: El master carga nuevas configuraciones; los antiguos workers se desconectan, mientras que los nuevos toman el relevo sin interrupciones. Con <em>worker_shutdown_timeout<\/em> Dejo que las solicitudes se completen correctamente sin bloquear recursos. Combino las implementaciones sin tiempo de inactividad en el servidor upstream con comprobaciones de estado y <em>proxy_next_upstream<\/em>-Establezco reglas para que los backends que fallan no aumenten la latencia global. Cuando realizo cambios en la configuraci\u00f3n, siempre modifico solo un par\u00e1metro y compruebo los efectos en los registros y las m\u00e9tricas; as\u00ed evito errores por confusi\u00f3n y mantengo la reproducibilidad del rendimiento.<\/p>\n\n<h2>Resumen conciso<\/h2>\n<p>Me acoplo <strong>procesos_trabajadores<\/strong> ajusto el n\u00famero de n\u00facleos (a ser posible, de forma autom\u00e1tica), configuro `worker_connections` en funci\u00f3n de la carga m\u00e1xima y aumento generosamente `rlimit_nofile` junto con los l\u00edmites del sistema operativo. En el bloque de eventos utilizo `epoll` y `multi_accept`, compruebo todo con pruebas de carga reproducibles y, a continuaci\u00f3n, realizo ajustes graduales. Para las cargas de trabajo de proxy, tengo en cuenta descriptores adicionales y pruebo la afinidad de la CPU cuando las cargas de trabajo son constantes. Una pila bien configurada con un kernel adecuado, una E\/S r\u00e1pida y par\u00e1metros de red razonables marca la diferencia. As\u00ed es como consigo <strong>NGINX<\/strong> confiable en el \u00e1mbito de rendimiento que requieren las p\u00e1ginas y las API m\u00e1s exigentes.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubre c\u00f3mo configurar correctamente los procesos de trabajo de NGINX y c\u00f3mo mejorar notablemente el rendimiento del servidor web mediante un ajuste espec\u00edfico de NGINX.<\/p>","protected":false},"author":1,"featured_media":20707,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20714","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"129","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"NGINX Worker","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20707","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20714","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=20714"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20714\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20707"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20714"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20714"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20714"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}