{"id":18056,"date":"2026-03-03T18:23:49","date_gmt":"2026-03-03T17:23:49","guid":{"rendered":"https:\/\/webhosting.de\/http-keepalive-timeout-server-performance-konfiguration\/"},"modified":"2026-03-03T18:23:49","modified_gmt":"2026-03-03T17:23:49","slug":"http-keepalive-timeout-server-performance-configuration","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/http-keepalive-timeout-server-performance-konfiguration\/","title":{"rendered":"HTTP Keep-Alive Timeout: configuraci\u00f3n \u00f3ptima para el rendimiento del servidor"},"content":{"rendered":"<p>Con la atenci\u00f3n puesta en <strong>Tiempo de espera HTTP Keep-Alive<\/strong> Le mostrar\u00e9 c\u00f3mo establecer tiempos de inactividad para que las conexiones se reutilicen sin bloquear hilos. Explico valores espec\u00edficos, muestro errores t\u00edpicos y proporciono configuraciones probadas para <strong>nginx<\/strong>, Apache y el sistema operativo.<\/p>\n\n<h2>Puntos centrales<\/h2>\n<ul>\n  <li><strong>Saldo<\/strong>: Demasiado corto aumenta los apretones de manos, demasiado largo bloquea los hilos.<\/li>\n  <li><strong>Valores<\/strong>Mayoritariamente 5-15 s y 100-500 peticiones por conexi\u00f3n.<\/li>\n  <li><strong>Coordinaci\u00f3n<\/strong>Coordinar los tiempos de espera de clientes, LB y cortafuegos.<\/li>\n  <li><strong>Casos especiales<\/strong>WebSockets, SSE, sondeo largo por separado.<\/li>\n  <li><strong>Monitoreo<\/strong>Monitoriza sockets abiertos, FDs y latencias.<\/li>\n<\/ul>\n\n<h2>HTTP Keep-Alive explicado brevemente<\/h2>\n<p>Mantengo conexiones TCP con <strong>Keep-Alive<\/strong> abierta para que varias peticiones utilicen la misma l\u00ednea. Esto ahorra repetidos apretones de manos TCP y TLS y reduce la <strong>CPU<\/strong>-notablemente. Esto es especialmente beneficioso para muchos archivos peque\u00f1os como iconos, JSON o CSS. Cada nueva conexi\u00f3n que se evita reduce los cambios de contexto y alivia las rutinas del n\u00facleo. En las pruebas con una alta proporci\u00f3n de GET, la duraci\u00f3n total se reduce significativamente porque se generan menos paquetes SYN\/ACK y fluye m\u00e1s tiempo de computaci\u00f3n hacia la l\u00f3gica de la aplicaci\u00f3n.<\/p>\n<p>Mido r\u00e1pidamente el efecto: las latencias medias m\u00f3viles se suavizan y el n\u00famero de nuevas conexiones TCP por segundo desciende. No lo consigo por arte de magia, sino por <strong>Reutilizaci\u00f3n de conexiones<\/strong> y l\u00edmites razonables. Sigue siendo importante que Keep-Alive no sustituya a un renderizado o almacenamiento en cach\u00e9 r\u00e1pidos. Acorta los tiempos de espera en la frontera de la red, mientras que la propia aplicaci\u00f3n debe seguir respondiendo con eficacia. Ambas cosas juntas aumentan el <strong>Actuaci\u00f3n<\/strong> notablemente.<\/p>\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\/03\/server-optimierung-4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comprender el tiempo de espera adecuado<\/h2>\n<p>El tiempo de espera define cu\u00e1nto tiempo permanece abierta una conexi\u00f3n inactiva antes de que el servidor la cierre. <strong>cierra<\/strong>. Si lo pongo demasiado corto, los clientes abren constantemente nuevas conexiones TCP, lo que <strong>Sobrecarga<\/strong> se eleva. Si lo establezco demasiado largo, las conexiones ociosas aparcan trabajadores o hilos preciosos. El arte reside en el equilibrio entre la reutilizaci\u00f3n y el consumo de recursos. Hago pruebas pr\u00e1cticas: primero lo establezco de forma aproximada y luego lo afino con pruebas de carga.<\/p>\n<p>Tambi\u00e9n presto atenci\u00f3n a la relaci\u00f3n entre tiempos de respuesta y ventanas de inactividad. Si la interacci\u00f3n t\u00edpica del usuario entre dos clics es de 2-4 segundos, un tiempo de espera de 5-15 segundos suele cubrir el patr\u00f3n real. Las llamadas cortas a la API pueden tolerar f\u00e1cilmente entre 5 y 10 segundos, y las cargas de trabajo multimedia, entre 10 y 15 segundos. Es importante no exagerar: los tiempos de espera excesivamente largos raramente conducen a m\u00e1s <strong>Rendimiento<\/strong>, pero a menudo conducen a bloqueos <strong>Recursos<\/strong>. Puedo reconocerlo r\u00e1pidamente por el creciente n\u00famero de enchufes abiertos y las elevadas cifras de FD.<\/p>\n\n<h2>Separar claramente los tipos de tiempo de espera<\/h2>\n<p>Hago una distinci\u00f3n estricta entre <strong>Tiempo de espera<\/strong> (Keep-Alive), <strong>Tiempo de espera de lectura\/cabecera<\/strong> (el tiempo que el servidor espera las peticiones entrantes) y <strong>Tiempo de espera de env\u00edo\/escritura<\/strong> (cu\u00e1nto tiempo se tolera el env\u00edo hacia el cliente). Estas categor\u00edas cumplen tareas diferentes:<\/p>\n<ul>\n  <li><strong>Tiempo de espera:<\/strong> Controla la reutilizaci\u00f3n y la duraci\u00f3n del estacionamiento de las conexiones inactivas.<\/li>\n  <li><strong>Tiempo de espera de lectura\/cabecera:<\/strong> Protege contra clientes lentos (lorises lentos) y cabeceras enviadas a medias.<\/li>\n  <li><strong>Tiempo de espera de env\u00edo\/escritura:<\/strong> Evita que el servidor espere interminablemente por una recepci\u00f3n lenta en el cliente.<\/li>\n<\/ul>\n<p>En <strong>nginx<\/strong> Utilizo deliberadamente header_timeout\/read_timeout y send_timeout por contexto (http\/servidor\/ubicaci\u00f3n) adem\u00e1s de keepalive_timeout. Desde las versiones m\u00e1s recientes configuro opcionalmente <strong>keepalive_time<\/strong>, para limitar la duraci\u00f3n m\u00e1xima de una conexi\u00f3n, aunque siga activa. En <strong>Apache<\/strong> Tambi\u00e9n utilizo <strong>RequestReadTimeout<\/strong> (mod_reqtimeout) y compruebe <strong>Tiempo de espera<\/strong> (global) separado de <strong>Tiempo de espera de KeepAlive<\/strong>. Esta separaci\u00f3n es un elemento importante para evitar la inmovilizaci\u00f3n de recursos sin ning\u00fan beneficio real.<\/p>\n\n<h2>Valores recomendados en la pr\u00e1ctica<\/h2>\n<p>Para entornos productivos, yo establezco un tiempo de espera de mantenimiento de la conexi\u00f3n de entre 5 y 15 segundos y entre 100 y 500 peticiones por conexi\u00f3n. Este intervalo consigue buenos \u00edndices de reutilizaci\u00f3n de conexiones y mantiene bajo el n\u00famero de conexiones inactivas. En <strong>nginx<\/strong> Uso keepalive_timeout 10s como valor inicial y keepalive_requests 200. Si hay mucho tr\u00e1fico, lo aumento moderadamente si veo demasiadas conexiones TCP nuevas. Si el tr\u00e1fico es escaso, lo vuelvo a bajar para evitar una avalancha de tr\u00e1fico ocioso.<\/p>\n<p>Los que profundicen m\u00e1s se beneficiar\u00e1n de un proceso de ajuste claro con puntos de medici\u00f3n. Para ello, resumo mis directrices en una gu\u00eda pr\u00e1ctica que describe el camino que va de la medici\u00f3n a la configuraci\u00f3n y al control. Para empezar r\u00e1pidamente, le remito a mis pasos en <a href=\"https:\/\/webhosting.de\/es\/http-mantener-vivo-ajuste-optimizacion-del-rendimiento-del-servidor-flujo\/\">Ajuste de Keep Alive<\/a>. C\u00f3mo controlar <strong>Reutilice<\/strong> y l\u00edmites y evitar sorpresas. Al final, lo que cuenta es una latencia baja con <strong>Rendimiento<\/strong>.<\/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\/03\/http-keep-alive-optimierung-1723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Riesgos de los tiempos de espera prolongados<\/h2>\n<p>Un tiempo de espera largo mantiene las conexiones artificiales <strong>abra<\/strong> y bloquea a los trabajadores aunque no siga ninguna petici\u00f3n. Esto hace que los sockets se hinchen y se dispare el n\u00famero de descriptores de fichero. Si el proceso alcanza sus l\u00edmites, veo rechazar errores de aceptaci\u00f3n o colas al establecer una conexi\u00f3n. La memoria crece, los recolectores de basura o asignadores cuestan tiempo adicional y la latencia aumenta. En caso de error, los clientes env\u00edan entonces a sockets que ya est\u00e1n cerrados y reciben cr\u00edpticos <strong>Error<\/strong>.<\/p>\n<p>Yo lo evito fijando valores moderados y comprobando regularmente las m\u00e9tricas. Si las conexiones inactivas aumentan demasiado con poca carga, reduzco el tiempo de espera. Si veo muchas conexiones nuevas por segundo durante los picos de tr\u00e1fico, lo aumento cuidadosamente en peque\u00f1os pasos. As\u00ed mantengo el <strong>Capacidad<\/strong> utilizables y evitar las conexiones muertas. El resultado es un sistema m\u00e1s fluido con menos <strong>Consejos<\/strong> en las curvas.<\/p>\n\n<h2>Configuraci\u00f3n: nginx, Apache y capa OS<\/h2>\n<p>Empiezo en el nivel del servidor web y establezco el tiempo de espera y los l\u00edmites. En <strong>nginx<\/strong> Establezco keepalive_timeout 5-15s y keepalive_requests 100-500. En Apache con event-MPM combino KeepAlive On, KeepAliveTimeout 5-15 y MaxKeepAliveRequests 100-500. Luego calibro worker o thread pools seg\u00fan la carga esperada. Esto evita que los KeepAlive ociosos se conviertan en productivos. <strong>Tragamonedas<\/strong> encuadernar.<\/p>\n<p>Aumento los l\u00edmites y las colas a nivel del sistema operativo. Establezco ulimit -n en al menos 100.000, ajusto net.core.somaxconn y tcp_max_syn_backlog y compruebo el manejo de TIME_WAIT. Esto asegura que el kernel y el proceso tienen suficiente <strong>Recursos<\/strong> proporcionar. Por \u00faltimo, verifico las rutas desde la NIC mediante el equilibrio de IRQ hasta la aplicaci\u00f3n. Esto me permite reconocer los cuellos de botella a tiempo y mantener el <strong>Latencia<\/strong> bajo.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Componente<\/th>\n      <th>Directiva\/Establecimiento<\/th>\n      <th>Recomendaci\u00f3n<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>nginx<\/td>\n      <td>tiempo de espera de keepalive<\/td>\n      <td>5-15 s<\/td>\n      <td><strong>M\u00e1s corto<\/strong> con poco tr\u00e1fico, m\u00e1s largo con muchas peticiones peque\u00f1as<\/td>\n    <\/tr>\n    <tr>\n      <td>nginx<\/td>\n      <td>keepalive_requests<\/td>\n      <td>100-500<\/td>\n      <td>Recicla compuestos y reduce <strong>Fugas<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Apache (evento)<\/td>\n      <td>Tiempo de espera de KeepAlive<\/td>\n      <td>5-15 s<\/td>\n      <td>Event-MPM gestiona el ralent\u00ed de forma m\u00e1s eficiente que <strong>prefork<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Sistema operativo<\/td>\n      <td>ulimit -n<\/td>\n      <td>\u2265 100.000<\/td>\n      <td>M\u00e1s FD abiertos para muchos <strong>Enchufes<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Sistema operativo<\/td>\n      <td>net.core.somaxconn<\/td>\n      <td>Aumentar<\/td>\n      <td>Menos conexiones rechazadas en <strong>Carga m\u00e1xima<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/server-optimization-http-keep-alive-4317.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Proxy inverso y reutilizaci\u00f3n ascendente<\/h2>\n<p>Siempre pienso en mantener vivo <strong>de extremo a extremo<\/strong>. Detr\u00e1s del servidor edge suele haber una cadena de proxy inverso \u2192 servidores de aplicaciones. Para nginx, activo mi propio <strong>Piscinas Keep Alive<\/strong> (upstream keepalive, keepalive_requests, keepalive_timeout), establecer proxy_http_version 1.1 y eliminar \u201eConnection: close\u201c. Esto tambi\u00e9n me ahorra <em>interno<\/em> y descargo los backends de las aplicaciones (Node.js, Java, PHP-FPM). En Apache con mod_proxy, tambi\u00e9n mantengo conexiones persistentes a servidores backend y las limito por destino para que un hotspot no monopolice los pools.<\/p>\n<p>Mido por separado: Tasa de reutilizaci\u00f3n Client\u2192Edge y Edge\u2192Backend. Si veo una buena reutilizaci\u00f3n en el borde, pero muchas conexiones nuevas al backend, aumento selectivamente los pools de subida. Esto me permite escalar sin aumentar globalmente los tiempos de espera del frontend.<\/p>\n\n<h2>Trabajadores, hilos y l\u00edmites del sistema operativo<\/h2>\n<p>No dimensiono trabajadores, eventos e hilos seg\u00fan valores deseados, sino seg\u00fan <strong>perfil de carga<\/strong>. Para ello, controlo las peticiones activas, los trabajadores inactivos, la utilizaci\u00f3n del bucle de eventos y los cambios de contexto. Si los hilos est\u00e1n aparcados en modo inactivo, reduzco el tiempo de espera o los l\u00edmites m\u00e1ximos de hilos inactivos. Si veo un 100% de CPU todo el tiempo, compruebo las colas de aceptaci\u00f3n, la distribuci\u00f3n de IRQ y la pila de red. Peque\u00f1as correcciones en los l\u00edmites de FD y en las acumulaciones suelen suponer una gran diferencia. <strong>Efectos<\/strong>.<\/p>\n<p>Planifico el margen de forma realista. Una reserva del 20-30% en hilos y FD proporciona seguridad para los picos. Si me excedo, pierdo cach\u00e9s y aumentan los residuos. Si me paso, las peticiones acaban en las colas o expiran. La intersecci\u00f3n correcta de <strong>Capacidad<\/strong> y eficiencia mantiene bajas las latencias y protege el <strong>Estabilidad<\/strong>.<\/p>\n\n<h2>Coordinar los tiempos de espera del cliente, el equilibrador de carga y el cortafuegos.<\/h2>\n<p>Establezco l\u00edmites de tiempo a lo largo de todo el camino para que no haya callejones sin salida. <strong>Conexiones<\/strong> se crean. Lo ideal es que los clientes cierren m\u00ednimamente antes que el servidor. El equilibrador de carga no debe cortar m\u00e1s corto, de lo contrario ver\u00e9 reinicios inesperados. Incluyo valores de inactividad de NAT y cortafuegos para que las conexiones no se pierdan en la ruta de la red. <strong>desaparecer<\/strong>. Este ajuste evita las retransmisiones y suaviza las curvas de carga.<\/p>\n<p>Mantengo la cadena comprensible con diagramas claros: Cliente \u2192 LB \u2192 servidor web \u2192 app. Documento los tiempos de espera en reposo, los tiempos de espera de lectura\/escritura y las estrategias de reintento para cada enlace. Si cambio un valor, compruebo los vecinos. As\u00ed mantengo la coherencia de la ruta y obtengo resultados de medici\u00f3n reproducibles. Esta disciplina ahorra tiempo en la <strong>Soluci\u00f3n de problemas<\/strong> y aumenta la <strong>fiabilidad<\/strong>.<\/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\/03\/optimal_configuration_server_9837.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Seguridad: Protecci\u00f3n contra los loros lentos y los abusos ociosos<\/h2>\n<p>Tiempos muertos demasiado generosos <strong>Superficies de ataque<\/strong>. Por lo tanto, establezco l\u00edmites que permiten la reutilizaci\u00f3n leg\u00edtima pero hacen m\u00e1s dif\u00edcil mantenerlos abiertos maliciosamente. En nginx, header y read_timeout, request_headers_size limits y un l\u00edmite superior duro para keepalive_requests ayudan. En Apache, uso mod_reqtimeout y limito las conexiones paralelas por IP. L\u00edmites de velocidad y <strong>limit_conn<\/strong> en nginx tambi\u00e9n protegen contra inundaciones de muchos sockets ociosos. Para los endpoints de larga ejecuci\u00f3n, separo pools dedicados para que los ataques a los flujos no comprometan a los trabajadores regulares de la API.<\/p>\n\n<h2>Casos especiales: Long Polling, SSE y WebSockets<\/h2>\n<p>Las corrientes largas chocan con las cortas <strong>Tiempos muertos<\/strong> y necesitan sus propias reglas. T\u00e9cnicamente, separo estos puntos finales de las rutas cl\u00e1sicas de API y activos. Para SSE y WebSockets, establezco tiempos de espera m\u00e1s altos, grupos de trabajadores dedicados y l\u00edmites estrictos por IP. Mantengo viva la conexi\u00f3n con heartbeats o ping\/pong y reconozco r\u00e1pidamente las desconexiones. De esta forma, los flujos no bloquean los hilos para las conexiones regulares. <strong>Peticiones cortas<\/strong>.<\/p>\n<p>Limito las conexiones simult\u00e1neas y mido activamente. Los l\u00edmites demasiado altos consumen FD y RAM. Los l\u00edmites demasiado estrechos cortan el acceso a los usuarios leg\u00edtimos. Encuentro el punto \u00f3ptimo con m\u00e9tricas limpias para conexiones abiertas, inactivas, activas y perdidas. Esta separaci\u00f3n me ahorra <strong>Aumenta<\/strong> los tiempos muertos y protege el <strong>Capacidad<\/strong>.<\/p>\n\n<h2>HTTP\/2, multiplexaci\u00f3n y keep-alive<\/h2>\n<p>HTTP\/2 multiplexa varios flujos a trav\u00e9s de un <strong>Conexi\u00f3n<\/strong>, pero sigue dependiendo de los tiempos de espera. Mantengo la ventana de inactividad moderada porque las sesiones tambi\u00e9n pueden aparcarse bajo HTTP\/2. Los keepalive_requests altos son menos importantes aqu\u00ed, pero el reciclaje sigue siendo \u00fatil. El bloqueo de cabeza de l\u00ednea se traslada al nivel de trama, por lo que sigo midiendo la latencia por <strong>Corriente<\/strong>. Si desea comparar con m\u00e1s detalle, encontrar\u00e1 informaci\u00f3n de fondo en <a href=\"https:\/\/webhosting.de\/es\/multiplexacion-http2-frente-a-rendimiento-http11-optimizacion-de-fondo\/\">Multiplexaci\u00f3n HTTP\/2<\/a>.<\/p>\n<p>En HTTP\/2, presto especial atenci\u00f3n al n\u00famero de flujos activos por conexi\u00f3n. Demasiados flujos paralelos pueden sobrecargar los hilos de la aplicaci\u00f3n. Entonces reduzco los l\u00edmites o aumento los trabajadores del servidor. Lo mismo se aplica aqu\u00ed: medir, ajustar, medir de nuevo. Esto mantiene el <strong>Tiempos de respuesta<\/strong> escasos y conservados <strong>Recursos<\/strong>.<\/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\/03\/dev_desk_HTTP_timeout_4783.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>TLS, reanudaci\u00f3n de sesi\u00f3n y HTTP\/3\/QUIC<\/h2>\n<p>Los apretones de manos TLS son caros. Yo uso <strong>Reanudaci\u00f3n de la sesi\u00f3n<\/strong> (tickets\/IDs) y grapado OCSP para que las reconexiones sean m\u00e1s r\u00e1pidas en caso de que finalice una conexi\u00f3n. En HTTP\/3, QUIC se hace cargo de la capa de transporte: aqu\u00ed el <strong>Tiempo de espera QUIC<\/strong> similar a Keep-Alive, pero sobre una base UDP. En este caso, tambi\u00e9n mantengo las ventanas moderadas y mido las retransmisiones, ya que las p\u00e9rdidas de paquetes tienen un efecto diferente que con TCP. Para entornos mixtos (H1\/H2\/H3), selecciono valores de referencia normalizados y hago ajustes finos para cada protocolo.<\/p>\n\n<h2>Supervisi\u00f3n, m\u00e9tricas y pruebas de carga<\/h2>\n<p>Conf\u00edo m\u00e1s en los datos de las mediciones que en mis corazonadas y empiezo por tener las cosas claras. <strong>Indicadores clave de rendimiento<\/strong>. Son importantes: sockets abiertos, utilizaci\u00f3n de FD, nuevas conexiones\/s, latencias (P50\/P90\/P99), tasas de error y retransmisiones. Ejecuto perfiles de carga realistas: Calentamiento, meseta, rampa de descenso. Luego comparo las curvas antes y despu\u00e9s de modificar el tiempo de espera. Un vistazo a <a href=\"https:\/\/webhosting.de\/es\/servidor-web-cola-latencia-gestion-de-solicitudes-cola-del-servidor\/\">Cola de servidores<\/a> ayuda a interpretar claramente los tiempos de espera.<\/p>\n<p>Documento cada ajuste con un sello de tiempo y los valores medidos. Esto me permite conservar el historial y reconocer las correlaciones. Me tomo en serio los efectos negativos y los revierto r\u00e1pidamente. Los pasos peque\u00f1os y comprensibles ahorran mucho tiempo. Al final, lo que cuenta es la estabilidad. <strong>Latencia<\/strong> y baja <strong>Tasa de error<\/strong> bajo carga.<\/p>\n\n<h2>M\u00e9todos y herramientas de medici\u00f3n en la pr\u00e1ctica<\/h2>\n<ul>\n  <li><strong>Pruebas r\u00e1pidas:<\/strong> Utilizo herramientas como wrk, ab o vegeta para comprobar las cuotas de reutilizaci\u00f3n (-H connection: keep-alive vs. close), las conexiones\/s y los percentiles de latencia.<\/li>\n  <li><strong>Vista del sistema:<\/strong> ss\/netstat muestra estados (ESTABLISHED, TIME_WAIT), lsof -p el consumo de FD, dmesg\/syslog indicaciones de ca\u00eddas.<\/li>\n  <li><strong>M\u00e9tricas del servidor web:<\/strong> nginx stub_status\/VTS y Apache mod_status proporcionan activo\/ocupado\/en espera y peticiones\/s. A partir de esto puedo reconocer picos de inactividad o cuellos de botella de los trabajadores.<\/li>\n  <li><strong>Rastros:<\/strong> Utilizo el rastreo distribuido para controlar si los tiempos de espera se producen en el l\u00edmite de la red o en la aplicaci\u00f3n.<\/li>\n<\/ul>\n\n<h2>Configurar paso a paso<\/h2>\n<p>En primer lugar, determino el patr\u00f3n de uso real: cu\u00e1ntas peticiones por sesi\u00f3n, qu\u00e9 <strong>Intervalos<\/strong> entre clics, c\u00f3mo de grandes son las respuestas. A continuaci\u00f3n, establezco un perfil inicial: timeout 10 s, keepalive_requests 200, n\u00famero moderado de trabajadores. A continuaci\u00f3n, realizo pruebas de carga con datos representativos. Eval\u00fao el n\u00famero de nuevas conexiones por segundo y la utilizaci\u00f3n del FD. A continuaci\u00f3n, ajusto el <strong>Valores<\/strong> en incrementos de 2-3 segundos.<\/p>\n<p>Repito el ciclo hasta que las latencias se mantienen estables bajo carga y los picos de FD no alcanzan el l\u00edmite. Con mucho tr\u00e1fico, s\u00f3lo aumento el tiempo de espera si veo claramente menos conexiones nuevas y los trabajadores siguen libres. Con una utilizaci\u00f3n baja, reduzco el tiempo de espera para evitar la inactividad. En casos especiales como SSE, establezco bloques de servidores dedicados con l\u00edmites m\u00e1s altos. Este camino conduce a un <strong>Configuraci\u00f3n<\/strong> sin cart\u00f3n de tarifa.<\/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\/03\/servereinstellung-performance-1987.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kubernetes, contenedores y autoescalado<\/h2>\n<p>En entornos de contenedores utilizo <strong>conntrack<\/strong>-l\u00edmites, l\u00edmites de pod FD y backlogs de nodos. Garantizo tiempos de espera coherentes entre Ingress, la malla de servicios\/proxy y la aplicaci\u00f3n. Para el autoescalado, presto atenci\u00f3n a <strong>Tiempos de drenaje<\/strong>Cuando se terminan los pods, deber\u00edan rechazar nuevas conexiones mediante \u201eConnection: close\u201c y servir las existentes limpiamente. Los valores Keep alive demasiado largos alargan los drenajes innecesariamente, mientras que los demasiado cortos generan tormentas de handshake al escalar.<\/p>\n\n<h2>Apagado gradual y despliegues continuos<\/h2>\n<p>Tambi\u00e9n tengo previsto desconectar. Antes de un despliegue, reduzco gradualmente Keep-Alive o env\u00edo dirigidos <strong>Conexi\u00f3n: cerrar<\/strong> en Respuestas para que los clientes no abran nuevas conexiones inactivas. En nginx, un <strong>worker_shutdown_timeout<\/strong> para las peticiones en ejecuci\u00f3n. En Apache, utilizo mecanismos de gracia y vigilo MaxConnectionsPerChild\/Worker para que el reciclaje se realice autom\u00e1ticamente con el tiempo. Esto mantiene los despliegues sin problemas sin tener que limitar los sockets abiertos.<\/p>\n\n<h2>Ajuste del sistema operativo: puertos, tiempos de espera, par\u00e1metros del kernel<\/h2>\n<ul>\n  <li><strong>puertos ef\u00edmeros:<\/strong> Seleccione un rango ip_local_port_amplio para que las conexiones de corta duraci\u00f3n no sufran escasez.<\/li>\n  <li><strong>TIME_WAIT:<\/strong> Vigilo los picos de TW. Las pilas modernas lo manejan bien; yo evito los picos dudosos (tw_recycle).<\/li>\n  <li><strong>tcp_keepalive_time:<\/strong> No lo estoy confundiendo con HTTP Keep-Alive. Es un mecanismo del kernel para reconocer pares muertos - \u00fatil detr\u00e1s de NAT, pero no un sustituto de la ventana de inactividad HTTP.<\/li>\n  <li><strong>Atrasos y topes:<\/strong> dimensiona somaxconn, tcp_max_syn_backlog y rmem\/wmem de forma sensata para no estrangular bajo carga.<\/li>\n<\/ul>\n\n<h2>Lista de comprobaci\u00f3n para la resoluci\u00f3n de problemas<\/h2>\n<ul>\n  <li><strong>Muchas conexiones nuevas a pesar de keep-alive:<\/strong> Tiempo de espera demasiado corto o los clientes\/LB se cortan antes.<\/li>\n  <li><strong>Altas cifras de ralent\u00ed y FDs completos:<\/strong> Tiempo de espera demasiado largo o grupos de trabajadores demasiado grandes para el patr\u00f3n de tr\u00e1fico.<\/li>\n  <li><strong>Error RST\/Timeout para sesiones largas:<\/strong> NAT\/firewall inactivo demasiado corto en la ruta, asimetr\u00eda entre enlaces.<\/li>\n  <li><strong>Latencias de cola larga (P99):<\/strong> Compruebe los tiempos de espera de env\u00edo y lectura, la lentitud de los clientes o el exceso de trabajo acumulado.<\/li>\n  <li><strong>Backends sobrecargados a pesar de la baja carga en los bordes:<\/strong> Falta jaula aguas arriba o es demasiado peque\u00f1a.<\/li>\n<\/ul>\n\n<h2>Perfiles de pr\u00e1cticas y valores iniciales<\/h2>\n<ul>\n  <li><strong>API-first (llamadas cortas):<\/strong> Keep-Alive 5-10 s, keepalive_requests 200-300, tight header\/read timeouts.<\/li>\n  <li><strong>Comercio electr\u00f3nico (mixto):<\/strong> 8-12 s, 200-400, un poco m\u00e1s generoso para im\u00e1genes de productos y visitas en cach\u00e9.<\/li>\n  <li><strong>Activos\/CDN-like (muchos archivos peque\u00f1os):<\/strong> 10-15 s, 300-500, fuertes pozas r\u00edo arriba y altos l\u00edmites de FD.<\/li>\n  <li><strong>Intranet\/baja carga:<\/strong> 5-8 s, 100-200, para que no domine el ralent\u00ed.<\/li>\n<\/ul>\n\n<h2>Brevemente resumido<\/h2>\n<p>Configuro el tiempo de espera HTTP keep-alive para que las conexiones se reutilicen sin bloquear hilos. En la pr\u00e1ctica, 5-15 segundos y 100-500 peticiones por conexi\u00f3n dan muy buenos resultados. Coordino los tiempos de espera del cliente, el equilibrador de carga y el cortafuegos, separo las conexiones de larga duraci\u00f3n como WebSockets y regulo los l\u00edmites del sistema operativo. Con una monitorizaci\u00f3n limpia, pruebas de carga realistas y peque\u00f1os pasos, consigo un bajo <strong>Latencias<\/strong> y alta <strong>Rendimiento<\/strong>. Quienes mantienen esta disciplina obtienen un rendimiento cuantificable del hardware existente.<\/p>","protected":false},"excerpt":{"rendered":"<p>Configuraci\u00f3n optimizada del tiempo de espera HTTP de mantenimiento de la conexi\u00f3n para mejorar el rendimiento del servidor. Gu\u00eda pr\u00e1ctica para el ajuste del servidor web y la gesti\u00f3n de conexiones.<\/p>","protected":false},"author":1,"featured_media":18049,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-18056","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":"848","_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":"HTTP Keep-Alive Timeout","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":"18049","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/18056","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=18056"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/18056\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/18049"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=18056"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=18056"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=18056"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}