{"id":20722,"date":"2026-08-17T08:35:37","date_gmt":"2026-08-17T06:35:37","guid":{"rendered":"https:\/\/webhosting.de\/nginx-worker-connections-skalierung-tausender-requests-trafficboost\/"},"modified":"2026-08-17T08:35:37","modified_gmt":"2026-08-17T06:35:37","slug":"nginx-ligacoes-dos-workers-escalabilidade-milhares-de-pedidos-aumento-do-trafego","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/nginx-worker-connections-skalierung-tausender-requests-trafficboost\/","title":{"rendered":"Liga\u00e7\u00f5es dos Workers do NGINX \u2013 Escalabilidade de milhares de pedidos para um desempenho m\u00e1ximo de alojamento"},"content":{"rendered":"<p>Estou a dimensionar o nginx worker de forma espec\u00edfica para lidar com milhares de pedidos simult\u00e2neos com baixo <strong>Lat\u00eancia<\/strong> para utilizar. A chave reside numa combina\u00e7\u00e3o equilibrada entre worker_processes, worker_connections, descritores de ficheiros e <strong>Eventos<\/strong>.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<ul>\n  <li><strong>Capacidade<\/strong> = worker_processes \u00d7 worker_connections; no caso de um proxy inverso, frequentemente atrav\u00e9s da liga\u00e7\u00e3o do cliente e da liga\u00e7\u00e3o upstream <strong>duplicado<\/strong>.<\/li>\n  <li><strong>Descritores de ficheiros<\/strong> (worker_rlimit_nofile, ulimit) de acordo com a carga de liga\u00e7\u00f5es prevista <strong>elevador<\/strong>.<\/li>\n  <li><strong>Eventos<\/strong>-Bloqueio com epoll, multi_accept e backlogs do kernel em condi\u00e7\u00f5es de carga elevada <strong>aparar<\/strong>.<\/li>\n  <li><strong>Monitoriza\u00e7\u00e3o<\/strong> atrav\u00e9s do `stub_status` e de testes de carga para itera\u00e7\u00f5es <strong>Personaliza\u00e7\u00e3o<\/strong>.<\/li>\n  <li><strong>Escalonamento<\/strong> Combinar na vertical e na horizontal, configura\u00e7\u00e3o <strong>dissociar<\/strong>.<\/li>\n<\/ul>\n\n<h2>Arquitetura do NGINX: Master, Worker e Eventos<\/h2>\n<p>O NGINX utiliza um processo principal que inicia v\u00e1rios processos de trabalho e os gere de forma eficiente com <strong>Eventos<\/strong> fornece. Em vez de processar threads por pedido, cada worker processa in\u00fameras liga\u00e7\u00f5es de forma n\u00e3o bloqueante atrav\u00e9s de um modelo baseado em eventos com baixo <strong>Despesas gerais<\/strong>. Defino a diretiva `worker_processes` como `auto`, para que o NGINX aproveite os n\u00facleos da CPU e cada unidade tenha o seu pr\u00f3prio worker. Desta forma, distribuo melhor as liga\u00e7\u00f5es recebidas e mantenho a lat\u00eancia baixa durante os picos de tr\u00e1fego <strong>baixo<\/strong>. Para uma abordagem mais aprofundada do planeamento dos processos, remeto para <a href=\"https:\/\/webhosting.de\/pt\/configurar-de-forma-ideal-os-processos-de-trabalho-do-nginx-para-melhorar-o-desempenho\/\">Otimizar os processos \u00abWorker\u00bb<\/a>, pois uma paraleliza\u00e7\u00e3o correta determina a capacidade de liga\u00e7\u00e3o vi\u00e1vel. \u00c9 fundamental que o par\u00e2metro \u00abworker_connections\u00bb seja dimensionado de forma adequada para cada \u00abworker\u00bb, para que a multiplica\u00e7\u00e3o por n\u00famero de processos resulte no valor esperado <strong>Carga de pico<\/strong> cobre.<\/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\/08\/nginx-worker-rechenzentrum-7421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>F\u00f3rmula de capacidade: worker_processes \u00d7 worker_connections<\/h2>\n<p>Calculo a capacidade aproximada com worker_processes \u00d7 worker_connections, tendo em conta que os pedidos redirecionados ocupam frequentemente duas liga\u00e7\u00f5es por acesso de utilizador, o que reduz o n\u00famero efetivo para metade <strong>pode<\/strong>. Muitas instala\u00e7\u00f5es padr\u00e3o come\u00e7am com 512 liga\u00e7\u00f5es por worker, o que, para cargas de trabalho produtivas, \u00e9 frequentemente insuficiente <strong>\u00e9<\/strong>. Os valores iniciais pr\u00e1ticos situam-se normalmente entre 1024 e 4096 e dependem do perfil de tr\u00e1fego e do hardware. Planeio com margem de seguran\u00e7a, ou seja, pelo menos o dobro da carga de pico medida, para garantir a gest\u00e3o segura dos picos de tr\u00e1fego <strong>amortecer<\/strong>. Continua a ser importante a valida\u00e7\u00e3o atrav\u00e9s de testes e m\u00e9tricas em tempo real, para que os n\u00fameros n\u00e3o se tornem um mero exerc\u00edcio te\u00f3rico <strong>tornar-se<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Cen\u00e1rio<\/strong><\/th>\n      <th><strong>processos_trabalhadores<\/strong><\/th>\n      <th><strong>liga\u00e7\u00f5es_trabalhadores<\/strong><\/th>\n      <th><strong>Teoricamente, no m\u00e1ximo.<\/strong><\/th>\n      <th><strong>Efetivo (Proxy)<\/strong><\/th>\n      <th><strong>FD por trabalhador<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Pequeno site<\/td>\n      <td>2<\/td>\n      <td>1024<\/td>\n      <td>2048<\/td>\n      <td>~1024<\/td>\n      <td>\u22651024<\/td>\n    <\/tr>\n    <tr>\n      <td>API com carga m\u00e9dia<\/td>\n      <td>4<\/td>\n      <td>2048<\/td>\n      <td>8192<\/td>\n      <td>~4096<\/td>\n      <td>\u22652048<\/td>\n    <\/tr>\n    <tr>\n      <td>Hor\u00e1rios de maior aflu\u00eancia na loja<\/td>\n      <td>8<\/td>\n      <td>4096<\/td>\n      <td>32768<\/td>\n      <td>~16384<\/td>\n      <td>\u22654096<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>HTTP\/1.1, HTTP\/2 e TLS: impacto nos workers e na lat\u00eancia<\/h2>\n<p>Os protocolos determinam o perfil da liga\u00e7\u00e3o. Com o HTTP\/1.1, observo frequentemente muitas liga\u00e7\u00f5es TCP simult\u00e2neas por cliente, enquanto o HTTP\/2 as reduz a um n\u00famero reduzido de fluxos, que, por sua vez, s\u00e3o mais intensamente utilizados <strong>feixes<\/strong>. Isto poupa descritores de ficheiros, mas transfere a carga para os buffers e para a prioriza\u00e7\u00e3o. No TLS, presto aten\u00e7\u00e3o \u00e0 reutiliza\u00e7\u00e3o de sess\u00f5es, para que n\u00e3o seja necess\u00e1rio realizar handshakes dispendiosos em cada pedido <strong>abrandar<\/strong>. Uma cache de sess\u00f5es partilhada e tempos de espera adequados reduzem os picos de utiliza\u00e7\u00e3o da CPU. Al\u00e9m disso, n\u00e3o defino o valor de keepalive_requests demasiado baixo, para que as liga\u00e7\u00f5es de longa dura\u00e7\u00e3o possam proporcionar as suas vantagens <strong>jogar fora<\/strong>. No caso do HTTP\/2, calculo uma maior simultaneidade por liga\u00e7\u00e3o e garanto que os buffers de envio\/rece\u00e7\u00e3o tenham dimens\u00e3o suficiente, sem ocupar mem\u00f3ria <strong>desperdi\u00e7ar<\/strong>. No caso de tr\u00e1fego misto, fa\u00e7o um planeamento conservador e verifico os efeitos por variante de protocolo no <strong>Teste<\/strong>.<\/p>\n\n<h2>Definir corretamente os descritores de ficheiros e o ulimit<\/h2>\n<p>Cada liga\u00e7\u00e3o necessita de, pelo menos, um descritor de ficheiro; no caso de um proxy reverso, s\u00e3o frequentemente necess\u00e1rios dois, raz\u00e3o pela qual valores baixos de ulimit podem causar s\u00e9rios <strong>Limites<\/strong> definir. Aumento o valor de `worker_rlimit_nofile` de forma a que `worker_processes` \u00d7 `worker_connections` seja vi\u00e1vel e haja reservas para registos, sockets e caches. A n\u00edvel do sistema, ajusto os ficheiros `limits.conf` e `fs.file-max` para que o sistema operativo permita o n\u00famero planeado de ficheiros abertos e n\u00e3o termine prematuramente <strong>trav\u00f5es<\/strong>. Atrav\u00e9s do comando `ulimit -n` e dos par\u00e2metros do Systemd (LimitNOFILE), verifico se a configura\u00e7\u00e3o se mant\u00e9m e se est\u00e1 adequada ao NGINX. Quem ignorar este ajuste ir\u00e1, apesar de um valor elevado de `worker_connections`, deparar-se subitamente com liga\u00e7\u00f5es rejeitadas e um aumento <strong>Lat\u00eancias<\/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\/08\/nginx_worker_connections_3894.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ajustar com precis\u00e3o o bloco de eventos: epoll, multi_accept, backlogs<\/h2>\n<p>No Linux, utilizo o epoll, uma vez que este mecanismo lida de forma eficiente com um grande n\u00famero de liga\u00e7\u00f5es atrav\u00e9s de <strong>Eventos<\/strong> gerencia. Com a op\u00e7\u00e3o \u00abmulti_accept\u00bb definida como \u00abon\u00bb, um trabalhador aceita v\u00e1rias novas liga\u00e7\u00f5es por evento, o que atenua os picos de carga e os atrasos na aceita\u00e7\u00e3o <strong>baixa<\/strong>. Aumento os par\u00e2metros do kernel, como net.core.somaxconn e net.ipv4.tcp_max_syn_backlog, de forma adequada, para que as filas de aceita\u00e7\u00e3o n\u00e3o transbordem durante picos de tr\u00e1fego. As otimiza\u00e7\u00f5es TIME_WAIT, como o tcp_tw_reuse, reduzem os estrangulamentos nas portas e mant\u00eam a curva de d\u00e9bito <strong>elevado<\/strong>. Para uma an\u00e1lise mais aprofundada sobre a multithreading e as filas, vale a pena consultar <a href=\"https:\/\/webhosting.de\/pt\/threadpool-servidor-web-apache-nginx-litespeed-otimizacao-configuracao\/\">Otimiza\u00e7\u00e3o do pool de threads<\/a>, mesmo que o NGINX funcione principalmente com base em eventos e, por isso, seja muito eficiente <strong>escalonado<\/strong>.<\/p>\n\n<h2>Distribuir corretamente os soquetes de lista: reuseport, backlog e accept_mutex<\/h2>\n<p>Quando h\u00e1 um grande n\u00famero de liga\u00e7\u00f5es simult\u00e2neas, procuro dimensionar ativamente a via de rece\u00e7\u00e3o. Com <strong>reutiliza\u00e7\u00e3o<\/strong> Cada worker recebe o seu pr\u00f3prio socket de escuta; assim, elimina-se a concorr\u00eancia na fun\u00e7\u00e3o `accept` e a carga \u00e9 distribu\u00edda de forma equilibrada por todos os n\u00facleos. Defino explicitamente o backlog de escuta para absorver picos de tr\u00e1fego de curta dura\u00e7\u00e3o. O `accept_mutex` j\u00e1 n\u00e3o \u00e9 necess\u00e1rio nesta configura\u00e7\u00e3o. Sem o `reuseport`, por outro lado, o `accept_mutex` pode <strong>ajudar<\/strong>, atenuar os efeitos de manada no \u00abAccept\u00bb. Importante: os tamanhos do backlog no NGINX e no kernel (somaxconn) devem <strong>encaixar<\/strong>, caso contr\u00e1rio, o efeito ser\u00e1 nulo.<\/p>\n<pre><code>events {\n    use epoll;\n    worker_connections 4096;\n    # accept_mutex on;   # com reuseport, na maioria das vezes, n\u00e3o \u00e9 necess\u00e1rio\n}\n\nserver {\n    listen 443 ssl http2 reuseport backlog=65535;\n    # ...\n}\n<\/code><\/pre>\n<p>Al\u00e9m disso,, sempre que necess\u00e1rio, atribuo os workers a n\u00facleos da CPU (worker_cpu_affinity), para que as linhas de cache e a carga de IRQ se mantenham est\u00e1veis. Em ambientes fortemente caracterizados por NUMA, isto reduz o <strong>Tr\u00e1fego transversal<\/strong> na mem\u00f3ria.<\/p>\n\n<h2>Proxy reverso, upstreams e Keep-Alive<\/h2>\n<p>Enquanto proxy reverso, o NGINX mant\u00e9m frequentemente duas liga\u00e7\u00f5es por cada pedido: uma com o cliente e outra com o backend, o que torna o planeamento da capacidade mais realista <strong>duplo<\/strong> \u00e9 importante. Ativo o Keep-Alive de forma adequada, para que as liga\u00e7\u00f5es upstream possam ser reutilizadas e a sobrecarga por pedido <strong>diminui\u00e7\u00f5es<\/strong>. Desta forma, reduzo a carga no PHP-FPM, no servidor de aplica\u00e7\u00f5es ou nos microsservi\u00e7os e liberto slots para novas sess\u00f5es de utilizador. O equil\u00edbrio entre os tempos de espera, o tempo de inatividade e a reutiliza\u00e7\u00e3o determina a efic\u00e1cia com que as liga\u00e7\u00f5es s\u00e3o recicladas <strong>tornar-se<\/strong>. Quem quiser ler mais sobre os conceitos b\u00e1sicos, pode consultar em <a href=\"https:\/\/webhosting.de\/pt\/ligacoes-persistentes-http-utilizacao-do-servidor-web-desempenho-da-rede\/\">Liga\u00e7\u00f5es persistentes<\/a> conselhos pr\u00e1ticos sobre a utiliza\u00e7\u00e3o da capacidade e a otimiza\u00e7\u00e3o da rede<strong>Use<\/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\/08\/nginx-worker-connections-scalability-2941.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Grupos de upstream, tempos limite e tentativas de repeti\u00e7\u00e3o<\/h2>\n<p>Para que os workers n\u00e3o tenham de esperar por backends lentos, mantenho tempos de espera reduzidos e tentativas de reenvio bem dosadas. Mantenho os conjuntos de keepalive a montante com dimens\u00e3o suficiente para que as liga\u00e7\u00f5es se mantenham ativas, mas n\u00e3o t\u00e3o grandes que os FD inativos ocupem mem\u00f3ria e slots <strong>vincular<\/strong>. Limito as tentativas de repeti\u00e7\u00e3o a um n\u00famero reduzido e s\u00f3 mudo de conex\u00e3o em caso de erros de transporte evidentes \u2013 assim evito o efeito \u00abthundering herd\u00bb em caso de pequenas falhas no backend.<\/p>\n<pre><code>upstream app_backend {\n    server 10.0.0.11:8080 max_fails=3 fail_timeout=10s;\n    server 10.0.0.12:8080 max_fails=3 fail_timeout=10s;\n    keepalive 64;  Conex\u00f5es upstream reutiliz\u00e1veis #\n}\n\nserver {\n    location \/ {\n proxy_pass http:\/\/app_backend;\n proxy_connect_timeout   2s;\n        proxy_read_timeout 15s;\n proxy_send_timeout 15s;\n proxy_next_upstream     error timeout http_502 http_503;\n proxy_next_upstream_tries 2;\n    }\n}\n<\/code><\/pre>\n<p>Ao mesmo tempo, ajusto os par\u00e2metros de Keep-Alive (tempos de espera, pedidos por liga\u00e7\u00e3o) para libertar rapidamente os recursos dos clientes que raramente est\u00e3o ativos <strong>autorizar<\/strong>.<\/p>\n\n<h2>Planear a escalabilidade de forma sensata: combinar a escalabilidade vertical e horizontal<\/h2>\n<p>Para volumes de tr\u00e1fego elevados, prefiro combinar o escalonamento vertical e o horizontal em <strong>Considera<\/strong>. Fa\u00e7o a escalabilidade vertical atrav\u00e9s de mais n\u00facleos de CPU, RAM, SSDs r\u00e1pidos e uma configura\u00e7\u00e3o de rede otimizada, para que cada worker funcione de forma fluida <strong>obras<\/strong>. Em termos horizontais, fa\u00e7o a expans\u00e3o com n\u00f3s NGINX sem estado, configura\u00e7\u00e3o gerida centralmente e registo distribu\u00eddo, para que a capacidade total aumente linearmente <strong>cresce<\/strong>. As caches locais e as pol\u00edticas bem definidas atrav\u00e9s do Maps ou da API permitem implementar altera\u00e7\u00f5es rapidamente. Esta separa\u00e7\u00e3o reduz os efeitos colaterais e ajuda a adaptar-se a novos padr\u00f5es de tr\u00e1fego sem necessidade de altera\u00e7\u00f5es em cada n\u00f3 <strong>servir<\/strong>.<\/p>\n\n<h2>Perspetiva de alojamento: lat\u00eancia, taxas de erro e experi\u00eancia<\/h2>\n<p>Um n\u00famero insuficiente de \u00abworker_connections\u00bb resulta em liga\u00e7\u00f5es rejeitadas, tempos de espera e um desempenho inferior <strong>Experi\u00eancia do utilizador<\/strong>. As aplica\u00e7\u00f5es din\u00e2micas, como os CMS ou as lojas online, sentem isso imediatamente, porque cada visualiza\u00e7\u00e3o de uma p\u00e1gina gera v\u00e1rias solicita\u00e7\u00f5es ao backend e os slots esgotam-se mais rapidamente <strong>curto<\/strong> ser\u00e3o. Por isso, come\u00e7o com valores moderados, como 1024 ou 2048 por worker, e vou aumentando-os gradualmente com base em valores de medi\u00e7\u00e3o reais. Paralelamente, mantenho os servi\u00e7os a montante a funcionar de forma eficiente e garanto que haja descritores de ficheiros suficientes, para que n\u00e3o surjam <strong>Limites<\/strong> aplicar. Os testes de desempenho demonstram que as plataformas cuidadosamente otimizadas oferecem vantagens reais neste contexto e gerem o tr\u00e1fego de pico de forma fi\u00e1vel <strong>interce\u00e7\u00e3o<\/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\/08\/nginx_worker_connections_performance_2394.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Mem\u00f3ria, armazenamento em buffer e percursos de E\/S<\/h2>\n<p>Cada liga\u00e7\u00e3o ocupa mem\u00f3ria de trabalho para metadados e buffers. Defino os valores de proxy_buffers, client_body_buffer_size e large_client_header_buffers de forma a que as solicita\u00e7\u00f5es t\u00edpicas caibam, sem alocar demasiada RAM de forma generalizada para o caso de valores at\u00edpicos <strong>vincular<\/strong>. No caso de conte\u00fados est\u00e1ticos, as op\u00e7\u00f5es \u00absendfile\u00bb e \u00abtcp_nopush\u00bb aceleram a entrega, enquanto a op\u00e7\u00e3o \u00abtcp_nodelay\u00bb \u00e9 indicada para respostas curtas em que a lat\u00eancia \u00e9 um fator cr\u00edtico <strong>Importante<\/strong> permanece. Se os ativos estiverem armazenados num suporte de armazenamento mais lento, o `aio threads` e o `thread_pool` ajudam a atenuar os efeitos de bloqueio. Com o `open_file_cache`, reduzo os acessos aos ficheiros e as chamadas ao `stat()`, mas tenho de ter em conta a necessidade adicional de FD. Gravo os registos em buffer (access_log \u2026 buffer=\u2026 flush=\u2026), para que os picos de E\/S n\u00e3o afetem os tempos de resposta <strong>influenciar<\/strong>.<\/p>\n\n<h2>Equil\u00edbrio entre seguran\u00e7a e desempenho do TLS<\/h2>\n<p>Os handshakes TLS exigem um grande consumo de CPU. Combino a reutiliza\u00e7\u00e3o de sess\u00f5es com par\u00e2metros de chave moderados e ativo otimiza\u00e7\u00f5es acumul\u00e1veis, como caches de sess\u00e3o e tickets, desde que sejam operacionais <strong>apto<\/strong>. O equil\u00edbrio ideal entre seguran\u00e7a e desempenho mant\u00e9m as lat\u00eancias est\u00e1veis, sem comprometer a qualidade da encripta\u00e7\u00e3o. Sob cargas mais elevadas, analiso separadamente os percentis 95 e 99, uma vez que, de outra forma, os picos de TLS ficariam ocultos por tr\u00e1s dos valores m\u00e9dios <strong>esconder<\/strong>. O HTTP\/2 reduz o n\u00famero de liga\u00e7\u00f5es, mas exige cuidado no controlo de fluxo e na compress\u00e3o de cabe\u00e7alhos, para manter sob controlo os perfis de CPU e de mem\u00f3ria <strong>manter<\/strong>.<\/p>\n\n<h2>Resili\u00eancia sob sobrecarga: limites e liberta\u00e7\u00e3o gradual<\/h2>\n<p>Para manter a lat\u00eancia, \u00e9 necess\u00e1rio um <strong>Modelagem<\/strong> indispens\u00e1vel em picos de carga. Com o `limit_conn`, limito as liga\u00e7\u00f5es paralelas por chave (por exemplo, IP ou sess\u00e3o); o `limit_req` reduz a carga de picos e protege os backends contra opera\u00e7\u00f5es s\u00edncronas <strong>Tempestades<\/strong>. Isolamos os pontos cr\u00edticos com regras mais rigorosas do que os recursos est\u00e1ticos. Se ocorrer um pico de tr\u00e1fego de curta dura\u00e7\u00e3o, devolvemos c\u00f3digos de erro 429\/503 bem definidos com \u00abRetry-After\u00bb, em vez de distribuir todas as solicita\u00e7\u00f5es de forma uniforme <strong>morrer de fome<\/strong> deixar. Suspendo as liga\u00e7\u00f5es persistentes (lingering_close) para libertar recursos de forma controlada e evitar padr\u00f5es do tipo Slowloris <strong>refutar<\/strong>. Este \u00abshedding\u00bb ativo mant\u00e9m a lat\u00eancia p95\/p99 dentro dos limites aceit\u00e1veis, mesmo quando a procura total ultrapassa, pontualmente, a capacidade nominal <strong>mentiras<\/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\/08\/hosting-performance-9047.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Integra\u00e7\u00e3o de contentores e sistemas: eliminar os limites l\u00e1 onde surgem<\/h2>\n<p>Nos contentores, aplicam-se frequentemente limites mais restritos. Verifico os limites do cgroup (CPU, RAM), defino o `ulimit -n` adequadamente dentro do contentor e incorporo o `LimitNOFILE` na defini\u00e7\u00e3o do servi\u00e7o. Os par\u00e2metros `sysctl`, como `somaxconn` e `tcp_max_syn_backlog`, t\u00eam de ser definidos no <strong>Anfitri\u00e3o<\/strong> entrem em vigor; os namespaces nem sempre isolam estas configura\u00e7\u00f5es de forma transparente. Em plataformas orquestradas, planeio a capacidade por pod\/n\u00f3, atribuo os workers a n\u00facleos espec\u00edficos e procuro garantir percursos de rede est\u00e1veis (por exemplo, sem saltos NAT desnecess\u00e1rios), para que a curva de lat\u00eancia <strong>calmo<\/strong> permanece. Acompanho as atualiza\u00e7\u00f5es cont\u00ednuas com o `worker_shutdown_timeout`, para que as liga\u00e7\u00f5es existentes sejam encerradas de forma correta <strong>chegar ao fim<\/strong>.<\/p>\n\n<h2>Monitoriza\u00e7\u00e3o e otimiza\u00e7\u00e3o iterativa<\/h2>\n<p>Sem visibilidade, as etapas de afina\u00e7\u00e3o continuam a ser <strong>Risco<\/strong>. Ativo o `stub_status` ou alternativas para monitorizar continuamente as liga\u00e7\u00f5es ativas, as taxas de aceita\u00e7\u00e3o e as rejei\u00e7\u00f5es. Nos testes de carga, simulo padr\u00f5es de acesso realistas e identifico pontos de estrangulamento nas filas de aceita\u00e7\u00e3o, nas lat\u00eancias a montante ou na CPU-<strong>Satura\u00e7\u00e3o<\/strong>. Em seguida, ajusto cuidadosamente o `worker_connections`, os processos, os limites de ficheiros e os par\u00e2metros TCP e verifico novamente o efeito. Este ciclo mant\u00e9m a plataforma fi\u00e1vel e evita surpresas em momentos inoportunos <strong>Tempos<\/strong>.<\/p>\n\n<h2>Configura\u00e7\u00e3o de exemplo e m\u00e9todo de c\u00e1lculo<\/h2>\n<p>Supondo que, nos hor\u00e1rios de pico, eu espere 2000 pedidos em curso simult\u00e2neos e utilize um proxy inverso, calculo, aproximadamente, 4000 slots de liga\u00e7\u00e3o mais <strong>Tamp\u00e3o<\/strong>. Se o NGINX estiver a funcionar em quatro n\u00facleos de CPU, come\u00e7o com, por exemplo, `worker_processes auto` e `worker_connections` entre 1000 e 2000 por processo de trabalho. Defino o limite de descritores de ficheiro por processo de trabalho num valor suficientemente elevado para que as liga\u00e7\u00f5es, os registos e os sockets internos tenham espa\u00e7o suficiente <strong>Local<\/strong> tenho. Configurei o bloco de eventos para epoll, ativei o multi_accept e aumentei os backlogs do kernel de acordo com o meu tr\u00e1fego de pico. Um trecho minimalista pode ter este aspeto, que depois ajusto com testes de desempenho <strong>Vota\u00e7\u00e3o<\/strong>:<\/p>\n<pre><code>worker_processes  auto;\nworker_rlimit_nofile  65535;\n\nevents {\n    use epoll;\n    worker_connections  2048;\n    multi_accept on;\n}\n\nhttp {\n    keepalive_timeout   65;\n    sendfile on;\n    # outras op\u00e7\u00f5es de proxy\/cache ...\n}\n<\/code><\/pre>\n<p>Al\u00e9m disso, estou a implementar otimiza\u00e7\u00f5es nas listas e no upstream para aperfei\u00e7oar o percurso de aceita\u00e7\u00e3o e o percurso do backend sob carga:<\/p>\n<pre><code>events {\n    use epoll;\n    worker_connections 4096;\n    # worker_cpu_affinity auto;  # atribuir n\u00facleos fixos, se necess\u00e1rio\n}\n\nhttp {\n    # Otimiza\u00e7\u00f5es de TLS\/sess\u00e3o a t\u00edtulo de exemplo\n    ssl_session_cache    shared:SSL:50m;\n    ssl_session_timeout  1h;\n\n upstream app_backend {\n server 10.0.0.11:8080;\n server 10.0.0.12:8080;\n keepalive 64;\n    }\n\n    server {\n listen 443 ssl http2 reuseport backlog=65535;\n\n location \/ {\n proxy_pass http:\/\/app_backend;\n proxy_connect_timeout     2s;\n            proxy_read_timeout 15s;\n proxy_next_upstream error timeout http_502 http_503;\n proxy_next_upstream_tries 2;\n }\n    }\n}\n<\/code><\/pre>\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\/developer_desk_nginx_5823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Em resumo: valores de refer\u00eancia concretos<\/h2>\n<p>Ajusto o valor de `worker_processes` de acordo com os n\u00facleos da CPU e, normalmente, defino o valor de `worker_connections` entre 1024 e <strong>4096<\/strong>. No caso do proxy reverso, prevejo duas liga\u00e7\u00f5es por pedido e mantenho, pelo menos, o dobro da margem em rela\u00e7\u00e3o ao pico medido de<strong>Carga<\/strong>. Defino o `worker_rlimit_nofile`, bem como os limites a n\u00edvel do sistema, a um valor suficientemente elevado para que os valores do ficheiro `nginx.conf` continuem a ser realmente utiliz\u00e1veis. No bloco `Events`, limito-o ao `epoll` e ao `multi_accept`, enquanto os backlogs do kernel absorvem breves picos de tr\u00e1fego <strong>amortecer<\/strong>. Atrav\u00e9s da monitoriza\u00e7\u00e3o e de ajustes graduais, transformo isso num motor de tr\u00e1fego fi\u00e1vel, capaz de gerir de forma eficaz o aumento do n\u00famero de visitas <strong>transporta<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubra como configurar corretamente as liga\u00e7\u00f5es dos workers do NGINX para escalar o NGINX de forma segura e maximizar o desempenho da hospedagem com milhares de pedidos.<\/p>","protected":false},"author":1,"featured_media":20715,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20722","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":"106","_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":"20715","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20722","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=20722"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20722\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20715"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20722"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20722"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20722"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}