{"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-configuracao-do-desempenho-do-servidor","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/http-keepalive-timeout-server-performance-konfiguration\/","title":{"rendered":"HTTP Keep-Alive Timeout: Configura\u00e7\u00e3o \u00f3ptima para o desempenho do servidor"},"content":{"rendered":"<p>Com o foco em <strong>Tempo limite do HTTP Keep-Alive<\/strong> Vou mostrar-lhe como definir tempos de inatividade para que as liga\u00e7\u00f5es sejam reutilizadas sem bloquear threads. Explico valores espec\u00edficos, mostro armadilhas t\u00edpicas e forne\u00e7o configura\u00e7\u00f5es testadas e comprovadas para <strong>nginx<\/strong>, Apache e o sistema operativo.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<ul>\n  <li><strong>Equil\u00edbrio<\/strong>O que \u00e9 que isso quer dizer?.<\/li>\n  <li><strong>Valores<\/strong>Na maioria dos casos, 5-15 s e 100-500 pedidos por liga\u00e7\u00e3o.<\/li>\n  <li><strong>Coordena\u00e7\u00e3o<\/strong>Coordenar os tempos limite do cliente, do LB e da firewall.<\/li>\n  <li><strong>Casos especiais<\/strong>WebSockets, SSE, Polling longo separadamente.<\/li>\n  <li><strong>Monitoriza\u00e7\u00e3o<\/strong>Monitorar sockets abertos, FDs e lat\u00eancias.<\/li>\n<\/ul>\n\n<h2>Breve explica\u00e7\u00e3o do HTTP Keep-Alive<\/h2>\n<p>Mantenho liga\u00e7\u00f5es TCP com <strong>Manter em perman\u00eancia<\/strong> aberto para que v\u00e1rios pedidos utilizem a mesma linha. Isto poupa os repetidos handshakes TCP e TLS e reduz o <strong>CPU<\/strong>-superf\u00edcie de forma not\u00e1vel. Isto \u00e9 particularmente ben\u00e9fico para muitos ficheiros pequenos, como \u00edcones, JSON ou CSS. Cada nova liga\u00e7\u00e3o evitada reduz as trocas de contexto e alivia as rotinas do kernel. Em benchmarks com uma elevada propor\u00e7\u00e3o de GET, a dura\u00e7\u00e3o total \u00e9 significativamente reduzida porque s\u00e3o gerados menos pacotes SYN\/ACK e mais tempo de computa\u00e7\u00e3o flui para a l\u00f3gica da aplica\u00e7\u00e3o.<\/p>\n<p>Me\u00e7o rapidamente o efeito: as lat\u00eancias m\u00e9dias m\u00f3veis tornam-se mais suaves e o n\u00famero de novas liga\u00e7\u00f5es TCP por segundo diminui. N\u00e3o consigo isso por m\u00e1gica, mas por <strong>Reutiliza\u00e7\u00e3o de liga\u00e7\u00f5es<\/strong> e limites sensatos. Continua a ser importante que o Keep-Alive n\u00e3o substitua a renderiza\u00e7\u00e3o r\u00e1pida ou o armazenamento em cache. Reduz os tempos de espera na fronteira da rede, enquanto a pr\u00f3pria aplica\u00e7\u00e3o deve continuar a responder de forma eficiente. Ambos juntos aumentam o <strong>Desempenho<\/strong> visivelmente.<\/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>Compreender o tempo limite correto<\/h2>\n<p>O tempo limite define o tempo que uma liga\u00e7\u00e3o inativa permanece aberta antes de o servidor a fechar. <strong>encerra<\/strong>. Se o definir demasiado curto, os clientes est\u00e3o constantemente a abrir novas liga\u00e7\u00f5es TCP, o que <strong>Despesas gerais<\/strong> \u00e9 aumentado. Se o definir durante demasiado tempo, as liga\u00e7\u00f5es inactivas estacionam trabalhadores ou threads preciosos. A arte reside no equil\u00edbrio entre a reutiliza\u00e7\u00e3o e o consumo de recursos. Fa\u00e7o testes pr\u00e1ticos: primeiro defino-o de forma aproximada, depois afino-o com testes de carga.<\/p>\n<p>Tamb\u00e9m presto aten\u00e7\u00e3o \u00e0 rela\u00e7\u00e3o entre os tempos de resposta e as janelas de inatividade. Se a intera\u00e7\u00e3o t\u00edpica do utilizador entre dois cliques for de 2-4 segundos, um timeout de 5-15 segundos cobre normalmente o padr\u00e3o real. As chamadas API curtas podem facilmente tolerar 5-10 segundos, as cargas de trabalho multim\u00e9dia 10-15 segundos. \u00c9 importante n\u00e3o exagerar: timeouts demasiado longos raramente levam a mais <strong>Rendimento<\/strong>, mas frequentemente conduzem a bloqueios <strong>Recursos<\/strong>. Reconhe\u00e7o-o rapidamente pelo n\u00famero crescente de tomadas abertas e pelos n\u00fameros elevados de FD.<\/p>\n\n<h2>Separar os tipos de tempo limite de forma clara<\/h2>\n<p>Fa\u00e7o uma distin\u00e7\u00e3o rigorosa entre <strong>Tempo limite de inatividade<\/strong> (Keep-Alive), <strong>Tempo limite de leitura\/cabe\u00e7alho<\/strong> (quanto tempo o servidor espera pelos pedidos recebidos) e <strong>Tempo limite de envio\/escrita<\/strong> (quanto tempo \u00e9 tolerado o envio para o cliente). Estas categorias desempenham diferentes fun\u00e7\u00f5es:<\/p>\n<ul>\n  <li><strong>Tempo limite de inatividade:<\/strong> Controla a reutiliza\u00e7\u00e3o e a dura\u00e7\u00e3o do estacionamento das liga\u00e7\u00f5es inactivas.<\/li>\n  <li><strong>Tempo limite de leitura\/cabe\u00e7alho:<\/strong> Protege contra clientes lentos (slow lorises) e cabe\u00e7alhos enviados pela metade.<\/li>\n  <li><strong>Tempo limite de envio\/escrita:<\/strong> Evita que o servidor espere infinitamente por uma rece\u00e7\u00e3o lenta no cliente.<\/li>\n<\/ul>\n<p>Em <strong>nginx<\/strong> Utilizo deliberadamente header_timeout\/read_timeout e send_timeout por contexto (http\/server\/location), para al\u00e9m de keepalive_timeout. Desde vers\u00f5es mais recentes, eu opcionalmente defino <strong>tempo de espera<\/strong>, para limitar o tempo de vida m\u00e1ximo de uma liga\u00e7\u00e3o, mesmo que esta se mantenha ativa. Em <strong>Apache<\/strong> Tamb\u00e9m utilizo <strong>RequestReadTimeout<\/strong> (mod_reqtimeout) e verificar <strong>Tempo limite<\/strong> (global) separado de <strong>Tempo de espera de manuten\u00e7\u00e3o de conex\u00e3o<\/strong>. Esta separa\u00e7\u00e3o \u00e9 um elemento importante para evitar a imobiliza\u00e7\u00e3o de recursos sem qualquer benef\u00edcio real.<\/p>\n\n<h2>Valores recomendados na pr\u00e1tica<\/h2>\n<p>Para ambientes produtivos, defino um tempo de espera de 5-15 segundos e 100-500 pedidos por liga\u00e7\u00e3o. Esse intervalo atinge boas taxas de reutiliza\u00e7\u00e3o de conex\u00e3o e mant\u00e9m baixo o n\u00famero de conex\u00f5es inativas. Em <strong>nginx<\/strong> Utilizo keepalive_timeout 10s como valor inicial e keepalive_requests 200. Se houver muito tr\u00e1fego, aumento-o moderadamente se vir demasiadas liga\u00e7\u00f5es TCP novas. Se o tr\u00e1fego for escasso, reduzo-o novamente para evitar uma inunda\u00e7\u00e3o de tr\u00e1fego inativo.<\/p>\n<p>Aqueles que se aprofundam beneficiar\u00e3o de um processo de afina\u00e7\u00e3o claro com pontos de medi\u00e7\u00e3o. Para tal, resumi as minhas orienta\u00e7\u00f5es num guia pr\u00e1tico que descreve o caminho da medi\u00e7\u00e3o \u00e0 configura\u00e7\u00e3o e ao controlo. Para um in\u00edcio r\u00e1pido, remeto-o para os meus passos em <a href=\"https:\/\/webhosting.de\/pt\/http-keep-alive-ajuste-otimizacao-do-desempenho-da-carga-do-servidor-fluxo\/\">Ajuste do Keep Alive<\/a>. Como controlar <strong>Reutiliza\u00e7\u00e3o<\/strong> e limites e evitar surpresas. No final, o que conta \u00e9 a baixa lat\u00eancia com <strong>Rendimento<\/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>Riscos de longos per\u00edodos de espera<\/h2>\n<p>Um tempo limite longo mant\u00e9m as liga\u00e7\u00f5es artificiais <strong>aberto<\/strong> e bloqueia os trabalhadores mesmo que n\u00e3o haja nenhum pedido a seguir. Isso faz com que os soquetes inchem e aumenta o n\u00famero de descritores de arquivo. Se o processo atingir os seus limites, vejo erros de aceita\u00e7\u00e3o de rejei\u00e7\u00e3o ou filas de espera ao estabelecer uma liga\u00e7\u00e3o. A mem\u00f3ria cresce, os colectores de lixo ou os alocadores custam tempo adicional e a lat\u00eancia aumenta. No caso de um erro, os clientes enviam para sockets que j\u00e1 est\u00e3o fechados e recebem <strong>Erro<\/strong>.<\/p>\n<p>Evito-o definindo valores moderados e verificando regularmente as m\u00e9tricas. Se as liga\u00e7\u00f5es inactivas aumentarem demasiado com pouca carga, reduzo o tempo limite. Se vejo muitas liga\u00e7\u00f5es novas por segundo durante os picos de tr\u00e1fego, aumento-o cuidadosamente em pequenos passos. \u00c9 assim que mantenho o <strong>Capacidade<\/strong> utiliz\u00e1vel e evitar liga\u00e7\u00f5es mortas. O resultado \u00e9 um sistema mais suave com menos <strong>Dicas<\/strong> nas curvas.<\/p>\n\n<h2>Configura\u00e7\u00e3o: nginx, Apache e camada do SO<\/h2>\n<p>Come\u00e7o ao n\u00edvel do servidor Web e defino o tempo limite e os limites. Em <strong>nginx<\/strong> Eu defino keepalive_timeout 5-15s e keepalive_requests 100-500. No Apache com event-MPM eu combino KeepAlive On, KeepAliveTimeout 5-15 e MaxKeepAliveRequests 100-500. Ent\u00e3o eu calibro os pools de workers ou threads de acordo com a carga esperada. Isso evita que keep-alives ociosos se tornem produtivos. <strong>Ca\u00e7a-n\u00edqueis<\/strong> ligar.<\/p>\n<p>Aumento os limites e as filas ao n\u00edvel do sistema operativo. Defino ulimit -n para pelo menos 100.000, ajusto net.core.somaxconn e tcp_max_syn_backlog e verifico o tratamento de TIME_WAIT. Isso garante que o kernel e o processo tenham <strong>Recursos<\/strong> fornecer. Finalmente, verifico os caminhos da placa de rede atrav\u00e9s do balanceamento de IRQ para a aplica\u00e7\u00e3o. Isto permite-me reconhecer atempadamente os estrangulamentos e manter o <strong>Lat\u00eancia<\/strong> baixo.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Componente<\/th>\n      <th>Diretiva\/Defini\u00e7\u00e3o<\/th>\n      <th>Recomenda\u00e7\u00e3o<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>nginx<\/td>\n      <td>tempo de espera de keepalive<\/td>\n      <td>5\u201315 s<\/td>\n      <td><strong>Mais curto<\/strong> com pouco tr\u00e1fego, mais tempo com muitos pedidos pequenos<\/td>\n    <\/tr>\n    <tr>\n      <td>nginx<\/td>\n      <td>keepalive_requests<\/td>\n      <td>100\u2013500<\/td>\n      <td>Recicla compostos e reduz <strong>Fugas<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Apache (evento)<\/td>\n      <td>Tempo de espera de manuten\u00e7\u00e3o de conex\u00e3o<\/td>\n      <td>5\u201315 s<\/td>\n      <td>O Event-MPM gere os inactivos de forma mais eficiente do que o <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>Mais FDs abertos para muitos <strong>Soquetes<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Sistema operativo<\/td>\n      <td>net.core.somaxconn<\/td>\n      <td>Aumentar<\/td>\n      <td>Menos liga\u00e7\u00f5es rejeitadas sob <strong>Carga de pico<\/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 invertido e reutiliza\u00e7\u00e3o a montante<\/h2>\n<p>Penso sempre em \"keep-alive <strong>de ponta a ponta<\/strong>. Por tr\u00e1s do servidor de borda, muitas vezes h\u00e1 uma cadeia de proxy reverso \u2192 servidores de aplicativos. Para o nginx, eu ativo meu pr\u00f3prio <strong>Piscinas Keep Alive<\/strong> (upstream keepalive, keepalive_requests, keepalive_timeout), definir proxy_http_version 1.1 e remover \u201eConnection: close\u201c. Isto tamb\u00e9m me poupa <em>interno<\/em> handshakes e descarregar backends de aplica\u00e7\u00f5es (Node.js, Java, PHP-FPM). No Apache com mod_proxy, tamb\u00e9m mantenho liga\u00e7\u00f5es persistentes aos servidores backend e limito-as por destino para que um hotspot n\u00e3o monopolize os pools.<\/p>\n<p>Me\u00e7o separadamente: taxa de reutiliza\u00e7\u00e3o Cliente\u2192Borda e Borda\u2192Backend. Se eu vir uma boa reutiliza\u00e7\u00e3o na borda, mas muitas conex\u00f5es novas para o backend, eu aumento seletivamente os pools upstream. Isso me permite escalar sem aumentar globalmente os tempos limite do frontend.<\/p>\n\n<h2>Trabalhadores, threads e limites do SO<\/h2>\n<p>N\u00e3o dimensiono trabalhadores, eventos e t\u00f3picos de acordo com os valores pretendidos, mas sim de acordo com <strong>perfil de carga<\/strong>. Para tal, monitorizo os pedidos activos, os trabalhadores inactivos, a utiliza\u00e7\u00e3o do ciclo de eventos e as mudan\u00e7as de contexto. Se as threads estiverem paradas em modo ocioso, reduzo o tempo limite ou os limites m\u00e1ximos de ociosidade por thread. Se vejo 100% de CPU o tempo todo, verifico as filas de aceita\u00e7\u00e3o, a distribui\u00e7\u00e3o de IRQ e a pilha de rede. Pequenas correc\u00e7\u00f5es aos limites de FD e aos atrasos fazem frequentemente uma grande diferen\u00e7a. <strong>Efeitos<\/strong>.<\/p>\n<p>Planeio a margem de manobra de forma realista. Uma reserva de 20-30 por cento em threads e FDs fornece seguran\u00e7a para picos. Se exagero, perco caches e o desperd\u00edcio aumenta. Se n\u00e3o o fizer, os pedidos acabam em filas de espera ou expiram. A intersec\u00e7\u00e3o correta de <strong>Capacidade<\/strong> e a efici\u00eancia mant\u00e9m as lat\u00eancias baixas e protege o <strong>Estabilidade<\/strong>.<\/p>\n\n<h2>Coordenar os tempos limite do cliente, do equilibrador de carga e da firewall<\/h2>\n<p>Estabele\u00e7o limites de tempo ao longo de todo o percurso para que n\u00e3o haja becos sem sa\u00edda. <strong>Liga\u00e7\u00f5es<\/strong> s\u00e3o criados. O ideal \u00e9 que os clientes fechem um pouco mais cedo do que o servidor. O equilibrador de carga n\u00e3o deve cortar mais cedo, caso contr\u00e1rio, verei reinicializa\u00e7\u00f5es inesperadas. Incluo valores de inatividade de NAT e firewall para que as liga\u00e7\u00f5es n\u00e3o se percam no caminho da rede. <strong>desaparecer<\/strong>. Esta afina\u00e7\u00e3o evita as retransmiss\u00f5es e suaviza as curvas de carga.<\/p>\n<p>Utilizo diagramas claros para manter a cadeia compreens\u00edvel: Cliente \u2192 LB \u2192 servidor Web \u2192 aplica\u00e7\u00e3o. Documentei os tempos de inatividade, os tempos de leitura\/escrita e as estrat\u00e9gias de repeti\u00e7\u00e3o para cada liga\u00e7\u00e3o. Se eu alterar um valor, verifico os vizinhos. Isto mant\u00e9m o caminho consistente e d\u00e1-me resultados de medi\u00e7\u00e3o reproduz\u00edveis. Esta disciplina poupa tempo na <strong>Resolu\u00e7\u00e3o de problemas<\/strong> e aumenta o <strong>fiabilidade<\/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>Seguran\u00e7a: Prote\u00e7\u00e3o contra loris lentos e abusos ociosos<\/h2>\n<p>Descontos de tempo abertos demasiado generosos <strong>Superf\u00edcies de ataque<\/strong>. Por isso, estabele\u00e7o limites que permitem uma reutiliza\u00e7\u00e3o leg\u00edtima, mas que tornam mais dif\u00edcil mant\u00ea-los abertos de forma maliciosa. No nginx, os limites de header e read_timeout, request_headers_size e um limite superior r\u00edgido para keepalive_requests ajudam. No Apache, eu uso mod_reqtimeout e limito conex\u00f5es paralelas por IP. Limites de taxa e <strong>limite_conex\u00e3o<\/strong> no nginx tamb\u00e9m protegem contra inunda\u00e7\u00f5es de muitos sockets ociosos. Para pontos de extremidade de longa dura\u00e7\u00e3o, separo pools dedicados para que os ataques a fluxos n\u00e3o vinculem os trabalhadores regulares da API.<\/p>\n\n<h2>Casos especiais: Long Polling, SSE e WebSockets<\/h2>\n<p>Os cursos de \u00e1gua longos chocam com os curtos <strong>Intervalos<\/strong> e precisam das suas pr\u00f3prias regras. Tecnicamente, separo estes pontos de extremidade da API cl\u00e1ssica e das rotas de activos. Para SSE e WebSockets, defino tempos limite mais elevados, pools de trabalhadores dedicados e limites r\u00edgidos por IP. Mantenho a liga\u00e7\u00e3o ativa com batimentos card\u00edacos ou ping\/pong e reconhe\u00e7o rapidamente as desconex\u00f5es. Dessa forma, os fluxos n\u00e3o bloqueiam threads para <strong>Pedidos curtos<\/strong>.<\/p>\n<p>Limito as liga\u00e7\u00f5es simult\u00e2neas e me\u00e7o-as ativamente. Os limites demasiado elevados consomem FDs e RAM. Os limites demasiado apertados cortam o acesso a utilizadores leg\u00edtimos. Eu encontro o ponto ideal com m\u00e9tricas limpas para conex\u00f5es abertas, ociosas, ativas e descartadas. Esta separa\u00e7\u00e3o permite-me poupar <strong>Aumentos<\/strong> os tempos limite e protege o <strong>Capacidade<\/strong>.<\/p>\n\n<h2>HTTP\/2, multiplexagem e keep-alive<\/h2>\n<p>O HTTP\/2 multiplexa v\u00e1rios fluxos atrav\u00e9s de um <strong>Liga\u00e7\u00e3o<\/strong>, mas continua dependente dos tempos limite. Mantenho a janela de inatividade moderada porque as sess\u00f5es tamb\u00e9m podem estacionar sob HTTP\/2. Os keepalive_requests elevados s\u00e3o menos importantes aqui, mas a reciclagem continua a ser \u00fatil. O bloqueio de cabe\u00e7a de linha passa para o n\u00edvel de quadro, ent\u00e3o continuo a medir a lat\u00eancia por <strong>Fluxo<\/strong>. Se quiser fazer uma compara\u00e7\u00e3o mais aprofundada, encontrar\u00e1 informa\u00e7\u00f5es de base em <a href=\"https:\/\/webhosting.de\/pt\/multiplexacao-http2-vs-desempenho-http11-antecedentes-otimizacao\/\">Multiplexa\u00e7\u00e3o HTTP\/2<\/a>.<\/p>\n<p>No HTTP\/2, presto especial aten\u00e7\u00e3o ao n\u00famero de fluxos activos por liga\u00e7\u00e3o. Demasiados fluxos paralelos podem sobrecarregar as threads da aplica\u00e7\u00e3o. Ent\u00e3o eu diminuo os limites ou aumento os trabalhadores do servidor. O mesmo se aplica aqui: medir, ajustar, medir novamente. Isso mant\u00e9m o <strong>Tempos de resposta<\/strong> escassos e preservados <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, retoma de sess\u00e3o e HTTP\/3\/QUIC<\/h2>\n<p>Os apertos de m\u00e3o TLS s\u00e3o caros. Eu uso <strong>Rein\u00edcio da sess\u00e3o<\/strong> (bilhetes\/IDs) e agrafagem OCSP, para que as reconex\u00f5es sejam mais r\u00e1pidas se a liga\u00e7\u00e3o terminar. No HTTP\/3, o QUIC assume a camada de transporte: aqui o <strong>Tempo limite de inatividade QUIC<\/strong> semelhante ao Keep-Alive, mas numa base UDP. Tamb\u00e9m neste caso, mantenho as janelas moderadas e me\u00e7o as retransmiss\u00f5es, uma vez que as perdas de pacotes t\u00eam um efeito diferente do que no TCP. Para ambientes mistos (H1\/H2\/H3), selecciono valores de refer\u00eancia normalizados e fa\u00e7o ajustes finos para cada protocolo.<\/p>\n\n<h2>Monitoriza\u00e7\u00e3o, m\u00e9tricas e testes de carga<\/h2>\n<p>Confio mais nos dados de medi\u00e7\u00e3o do que no meu instinto e come\u00e7o por uma abordagem clara <strong>KPIs<\/strong>. S\u00e3o importantes: sockets abertos, utiliza\u00e7\u00e3o do FD, novas liga\u00e7\u00f5es\/s, lat\u00eancias (P50\/P90\/P99), taxas de erro e retransmiss\u00f5es. Executo perfis de carga realistas: Aquecimento, plat\u00f4, rampa de descida. Em seguida, comparo as curvas antes e depois das altera\u00e7\u00f5es ao timeout. Um olhar sobre <a href=\"https:\/\/webhosting.de\/pt\/servidor-web-fila-latencia-tratamento-de-pedidos-fila-do-servidor\/\">Fila de espera do servidor<\/a> ajuda a interpretar claramente os tempos de espera.<\/p>\n<p>Registo todos os ajustes com um carimbo de data\/hora e os valores medidos. Isto permite-me preservar o hist\u00f3rico e reconhecer as correla\u00e7\u00f5es. Levo a s\u00e9rio os efeitos negativos e reverto-os rapidamente. Passos pequenos e compreens\u00edveis poupam muito tempo. O que conta no final \u00e9 um sistema est\u00e1vel <strong>Lat\u00eancia<\/strong> e baixo <strong>Taxa de erro<\/strong> sob carga.<\/p>\n\n<h2>M\u00e9todos e instrumentos de medi\u00e7\u00e3o na pr\u00e1tica<\/h2>\n<ul>\n  <li><strong>Testes r\u00e1pidos:<\/strong> Utilizo ferramentas como o wrk, ab ou vegeta para verificar as quotas de reutiliza\u00e7\u00e3o (-H connection: keep-alive vs. close), as liga\u00e7\u00f5es\/s e os percentis de lat\u00eancia.<\/li>\n  <li><strong>Vista do sistema:<\/strong> ss\/netstat mostra os estados (ESTABLISHED, TIME_WAIT), lsof -p o consumo de FD, dmesg\/syslog as indica\u00e7\u00f5es de quedas.<\/li>\n  <li><strong>M\u00e9tricas do servidor Web:<\/strong> O stub_status\/VTS do nginx e o mod_status do Apache fornecem os dados de ativo\/ inativo\/espera e pedidos\/s. A partir da\u00ed, posso reconhecer picos de inatividade ou estrangulamentos de trabalho.<\/li>\n  <li><strong>Tra\u00e7os:<\/strong> Utilizo o rastreio distribu\u00eddo para monitorizar se os tempos de espera ocorrem no limite da rede ou na aplica\u00e7\u00e3o.<\/li>\n<\/ul>\n\n<h2>Configurar passo a passo<\/h2>\n<p>Primeiro, determino o padr\u00e3o de utiliza\u00e7\u00e3o real: quantos pedidos por sess\u00e3o, que <strong>Intervalos<\/strong> entre cliques, qual o tamanho das respostas. Em seguida, defino um perfil inicial: timeout 10 s, keepalive_requests 200, n\u00famero moderado de trabalhadores. De seguida, realizo testes de carga com dados representativos. Avalio o n\u00famero de novas liga\u00e7\u00f5es por segundo e a utiliza\u00e7\u00e3o do FD. Em seguida, ajusto o <strong>Valores<\/strong> em incrementos de 2-3 segundos.<\/p>\n<p>Repito o ciclo at\u00e9 que as lat\u00eancias permane\u00e7am est\u00e1veis sob carga e os picos de FD n\u00e3o atinjam o limite. Com tr\u00e1fego intenso, s\u00f3 aumento o tempo limite se vir claramente menos liga\u00e7\u00f5es novas e os trabalhadores continuarem livres. Com baixa utiliza\u00e7\u00e3o, reduzo o tempo limite para evitar ociosidade. Em casos especiais, como o SSE, defino blocos de servidores dedicados com limites mais altos. Esse caminho leva a uma solu\u00e7\u00e3o resiliente <strong>Defini\u00e7\u00e3o<\/strong> sem cart\u00e3o de taxas.<\/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, contentores e escalonamento autom\u00e1tico<\/h2>\n<p>Em ambientes de contentor, utilizo <strong>conetor<\/strong>-limites, limites de FD de pod e atrasos de n\u00f3s. Garanto tempos limite de inatividade consistentes entre o Ingress, o service mesh\/proxy e a aplica\u00e7\u00e3o. Para o escalonamento autom\u00e1tico, presto aten\u00e7\u00e3o a <strong>Tempos de drenagem<\/strong>Quando os pods s\u00e3o terminados, eles devem rejeitar novas conex\u00f5es via \u201eConnection: close\u201c e servir as existentes de forma limpa. Os valores de keep alive que s\u00e3o muito longos estendem os drenos desnecessariamente, enquanto aqueles que s\u00e3o muito curtos geram tempestades de handshake ao escalar para fora.<\/p>\n\n<h2>Encerramento gracioso e implementa\u00e7\u00f5es cont\u00ednuas<\/h2>\n<p>Tamb\u00e9m tenciono desligar-me. Antes de uma implementa\u00e7\u00e3o, reduzo gradualmente o Keep-Alive ou envio mensagens direcionadas <strong>Liga\u00e7\u00e3o: fechar<\/strong> nas respostas para que os clientes n\u00e3o abram novas conex\u00f5es ociosas. No nginx, um <strong>worker_shutdown_timeout<\/strong> para os pedidos em curso. No Apache, utilizo mecanismos graciosos e mantenho um olho no MaxConnectionsPerChild\/Worker para que a reciclagem ocorra automaticamente ao longo do tempo. Isso mant\u00e9m as implementa\u00e7\u00f5es suaves sem limitar os sockets abertos.<\/p>\n\n<h2>Afina\u00e7\u00e3o do SO: portas, tempos limite, par\u00e2metros do kernel<\/h2>\n<ul>\n  <li><strong>portos ef\u00e9meros:<\/strong> Selecione um intervalo amplo para ip_local_port_range, de modo a que as liga\u00e7\u00f5es de curta dura\u00e7\u00e3o n\u00e3o se deparem com escassez.<\/li>\n  <li><strong>TIME_WAIT:<\/strong> Observo os picos de TW. As pilhas modernas lidam bem com isso; evito ajustes duvidosos (tw_recycle).<\/li>\n  <li><strong>tcp_keepalive_time:<\/strong> N\u00e3o estou a confundi-lo com o HTTP Keep-Alive. \u00c9 um mecanismo do kernel para reconhecer pares mortos - \u00fatil atr\u00e1s de NAT, mas n\u00e3o um substituto para a janela de inatividade HTTP.<\/li>\n  <li><strong>Atrasos e amortecedores:<\/strong> dimensionar somaxconn, tcp_max_syn_backlog e rmem\/wmem de forma sensata para n\u00e3o estrangular sob carga.<\/li>\n<\/ul>\n\n<h2>Lista de verifica\u00e7\u00e3o de resolu\u00e7\u00e3o de problemas<\/h2>\n<ul>\n  <li><strong>Muitas novas liga\u00e7\u00f5es\/s apesar do keep-alive:<\/strong> Timeout demasiado curto ou clientes\/LB cortados mais cedo.<\/li>\n  <li><strong>Valores elevados de inatividade e FDs completos:<\/strong> Timeout demasiado longo ou pools de trabalhadores demasiado grandes para o padr\u00e3o de tr\u00e1fego.<\/li>\n  <li><strong>Erro RST\/Timeout para sess\u00f5es mais longas:<\/strong> NAT\/firewall ocioso demasiado curto no caminho, assimetria entre liga\u00e7\u00f5es.<\/li>\n  <li><strong>Lat\u00eancias de cauda longa (P99):<\/strong> Verifique os tempos limite de envio\/leitura, os clientes lentos ou as listas de pend\u00eancias demasiado preenchidas.<\/li>\n  <li><strong>Backends sobrecarregados apesar da baixa carga de borda:<\/strong> A gaiola a montante n\u00e3o existe ou \u00e9 demasiado pequena.<\/li>\n<\/ul>\n\n<h2>Perfis de pr\u00e1tica e valores iniciais<\/h2>\n<ul>\n  <li><strong>API-first (chamadas curtas):<\/strong> Keep-Alive 5-10 s, keepalive_requests 200-300, timeouts apertados de cabe\u00e7alho\/leitura.<\/li>\n  <li><strong>Com\u00e9rcio eletr\u00f3nico (misto):<\/strong> 8-12 s, 200-400, um pouco mais generoso para imagens de produtos e visitas ao cache.<\/li>\n  <li><strong>Tipo Assets\/CDN (muitos ficheiros pequenos):<\/strong> 10-15 s, 300-500, po\u00e7as fortes a montante e limites elevados de FD.<\/li>\n  <li><strong>Intranet\/baixa carga:<\/strong> 5-8 s, 100-200, para que o ralenti n\u00e3o seja dominante.<\/li>\n<\/ul>\n\n<h2>Brevemente resumido<\/h2>\n<p>Defino o tempo limite de HTTP keep-alive para que as liga\u00e7\u00f5es sejam reutilizadas sem bloquear as threads. Na pr\u00e1tica, 5-15 segundos e 100-500 pedidos por liga\u00e7\u00e3o d\u00e3o resultados muito bons. Coordeno os tempos limite do cliente, do equilibrador de carga e da firewall, separo as liga\u00e7\u00f5es de longa dura\u00e7\u00e3o, como as WebSockets, e regulo os limites do SO. Com uma monitoriza\u00e7\u00e3o limpa, testes de carga realistas e pequenos passos, consigo obter baixos <strong>Lat\u00eancias<\/strong> e elevado <strong>Rendimento<\/strong>. Aqueles que mant\u00eam esta disciplina obt\u00eam um desempenho mensur\u00e1vel do hardware existente.<\/p>","protected":false},"excerpt":{"rendered":"<p>Defini\u00e7\u00f5es optimizadas do tempo limite do HTTP keep-alive para um melhor desempenho do servidor. Guia pr\u00e1tico para afina\u00e7\u00e3o de servidores Web e gest\u00e3o de liga\u00e7\u00f5es.<\/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":"843","_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\/pt\/wp-json\/wp\/v2\/posts\/18056","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=18056"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/18056\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/18049"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=18056"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=18056"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=18056"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}