{"id":20714,"date":"2026-08-16T18:19:23","date_gmt":"2026-08-16T16:19:23","guid":{"rendered":"https:\/\/webhosting.de\/nginx-worker-processes-optimal-konfigurieren-performanceboost\/"},"modified":"2026-08-16T18:19:23","modified_gmt":"2026-08-16T16:19:23","slug":"configurar-de-forma-ideal-os-processos-de-trabalho-do-nginx-para-melhorar-o-desempenho","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/nginx-worker-processes-optimal-konfigurieren-performanceboost\/","title":{"rendered":"Configurar de forma ideal os processos de trabalho do NGINX para obter o m\u00e1ximo desempenho"},"content":{"rendered":"<p>Eu configuro <strong>NGINX Worker<\/strong> de forma a que os par\u00e2metros `worker_processes`, `worker_connections` e `worker_rlimit_nofile` estejam perfeitamente sincronizados e o Epoll funcione no ciclo de eventos. Assim, utilizo <strong>N\u00facleos de CPU<\/strong> seja eficiente, permita dimensionar de forma planeada as liga\u00e7\u00f5es simult\u00e2neas e mantenha as lat\u00eancias baixas nos picos de carga.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<p>Os aspetos fundamentais que se seguem fornecem-te orienta\u00e7\u00f5es imediatas para uma configura\u00e7\u00e3o robusta do NGINX Worker.<\/p>\n<ul>\n  <li><strong>processos_trabalhadores<\/strong> associar ao n\u00famero de n\u00facleos l\u00f3gicos, de prefer\u00eancia com \u201eauto\u201c.<\/li>\n  <li><strong>liga\u00e7\u00f5es_trabalhadores<\/strong> ajustar de forma a que os picos reais sejam facilmente cobertos.<\/li>\n  <li><strong>rlimit_nofile<\/strong> e aumentar os limites do sistema operativo de acordo com o volume de tr\u00e1fego.<\/li>\n  <li><strong>epoll<\/strong> e ativar o multi_accept para tirar partido do ciclo de eventos de forma eficiente.<\/li>\n  <li><strong>Ensaios de carga<\/strong> avan\u00e7ar e ir ajustando com precis\u00e3o, passo a passo.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-optimierung-serverraum-5961.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Arquitetura do NGINX: Compreender os servidores \u00abMaster\u00bb e \u00abWorker\u00bb<\/h2>\n<p>Separo as tarefas de <strong>Mestre<\/strong> e os Workers: o Master carrega as configura\u00e7\u00f5es, abre sockets e inicia processos, enquanto os Workers processam os pedidos no evento-loop. Cada Worker funciona de forma aut\u00f3noma, reage a eventos e consegue gerir milhares de liga\u00e7\u00f5es sem causar bloqueios. Este modelo revela todo o seu potencial quando distribuo adequadamente os n\u00facleos da CPU e utilizo o ciclo de eventos de forma otimizada atrav\u00e9s do epoll. Tenho em conta que cada salto adicional do proxy consome recursos de liga\u00e7\u00e3o, o que se reflete nos limites. Quem compreende as fun\u00e7\u00f5es decide conscientemente sobre <strong>Recursos<\/strong> e evita gargalos numa fase precoce.<\/p>\n\n<h2>Combinar corretamente as tr\u00eas diretrizes fundamentais<\/h2>\n<p>Considero <strong>processos_trabalhadores<\/strong>, worker_connections e worker_rlimit_nofile nunca isoladamente, mas sim como um todo. O n\u00famero total de liga\u00e7\u00f5es poss\u00edveis resulta da multiplica\u00e7\u00e3o do n\u00famero de trabalhadores pelo n\u00famero de liga\u00e7\u00f5es por trabalhador; a partir da\u00ed, deduzo os limites para os descritores de ficheiros. Se estes par\u00e2metros n\u00e3o estiverem em sintonia, deparo-me com o erro \u201etoo many open files\u201c ou com timeouts severos. Para cargas elevadas, preciso de uma cadeia coerente: processos suficientes, liga\u00e7\u00f5es generosas, um rlimit_nofile devidamente aumentado e par\u00e2metros do sistema operativo adequados. Assim, evito que um valor demasiado pequeno <strong>Limite<\/strong> castrou toda a capacidade.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_worker_meeting_3021.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>worker_processes: selecionar o n\u00famero de forma espec\u00edfica<\/h2>\n<p>Eu fixo <strong>processos_trabalhadores<\/strong> normalmente em \u201eauto\u201c, para que o NGINX detete o n\u00famero de n\u00facleos l\u00f3gicos da CPU e possa utilizar cada n\u00facleo. Um worker por n\u00facleo evita mudan\u00e7as de contexto desnecess\u00e1rias e distribui a carga de forma eficiente, o que permite manter o tempo de resposta previs\u00edvel. Em m\u00e1quinas com um n\u00famero muito elevado de n\u00facleos, testo deliberadamente n\u00fameros mais baixos de workers para comparar os acertos de cache e a utiliza\u00e7\u00e3o dos n\u00facleos. Se as m\u00e9tricas indicarem que os n\u00facleos est\u00e3o sobrecarregados ou que as falhas de TLB est\u00e3o a aumentar, ajusto o n\u00famero de workers gradualmente. Primeiro medir, depois alterar \u2013 \u00e9 assim que garanto resultados fi\u00e1veis <strong>Resultados<\/strong>.<\/p>\n\n<h2>worker_connections: aumentar as liga\u00e7\u00f5es de forma program\u00e1vel<\/h2>\n<p>Eu escolho o <strong>liga\u00e7\u00f5es_trabalhadores<\/strong> dependendo do tr\u00e1fego de destino e da combina\u00e7\u00e3o de protocolos, come\u00e7ando frequentemente em 2048 ou 4096. Para APIs com elevado tr\u00e1fego, considero 8192, desde que os limites do sistema operativo e a mem\u00f3ria RAM o permitam. Verifico cada aumento com testes de carga, porque as liga\u00e7\u00f5es abertas ocupam mem\u00f3ria e influenciam o comportamento a montante. Quando os handshakes SSL ou uploads de grande volume predominam, oriento-me mais pelos perfis de CPU e E\/S, e n\u00e3o apenas pelos n\u00fameros brutos de liga\u00e7\u00f5es. Desta forma, garanto que o n\u00famero definido por trabalhador <strong>Capacidade<\/strong> e que continue a ser realmente utiliz\u00e1vel.<\/p>\n\n<h2>Sincronizar o `worker_rlimit_nofile` com os limites do sistema operativo<\/h2>\n<p>Vou garantir que <strong>rlimit_nofile<\/strong> cobre, pelo menos, a capacidade total te\u00f3rica e \u00e9 frequentemente configurado com uma margem de seguran\u00e7a. Para cen\u00e1rios de proxy reverso, calculo um segundo descritor para o upstream por cada liga\u00e7\u00e3o de cliente. Assim, costumo definir o rlimit_nofile com um valor duas vezes superior ao n\u00famero esperado de liga\u00e7\u00f5es simult\u00e2neas. Aumento os limites do kernel e do utilizador (ulimit -n, fs.file-max) de forma a que o NGINX consiga efetivamente atingir esses valores. Se surgirem mensagens relativas a ficheiros abertos no registo de erros, aumentei rapidamente os limites e observo a <strong>Lat\u00eancia<\/strong> novamente sob carga.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-performance-optimization-5123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bloco de eventos: utilizar eficazmente o epoll e o multi_accept<\/h2>\n<p>Ativo no bloco \u00abEventos\u00bb <strong>epoll<\/strong> e defino o multi_accept como \u201eon\u201c, para que os workers aceitem as liga\u00e7\u00f5es em espera de uma s\u00f3 vez. O epoll reduz a sobrecarga quando h\u00e1 muitos sockets simult\u00e2neos e est\u00e1 em sintonia com o design n\u00e3o bloqueante do NGINX. Estas op\u00e7\u00f5es revelam-se vantajosas em picos de tr\u00e1fego, pois aceleram a fase de aceita\u00e7\u00e3o e permitem avan\u00e7ar mais rapidamente para o processamento propriamente dito. No Linux, esta \u00e9 a minha configura\u00e7\u00e3o padr\u00e3o, que s\u00f3 alterei em casos especiais raros. Quem quiser aprofundar o assunto pode comparar o modelo de loop de eventos com <a href=\"https:\/\/webhosting.de\/pt\/threadpool-servidor-web-apache-nginx-litespeed-otimizacao-configuracao\/\">Threadpool vs. Evento-Loop<\/a> e conclui que <strong>conclus\u00f5es<\/strong> para o pr\u00f3prio ambiente.<\/p>\n\n<h2>Afinidade da CPU: associar os workers aos n\u00facleos<\/h2>\n<p>Eu fixo <strong>worker_cpu_affinity<\/strong> de forma direcionada, quando as cargas de trabalho s\u00e3o constantes e dependentes da CPU. Distribuo o esquema de atribui\u00e7\u00e3o atrav\u00e9s de m\u00e1scaras de bits, para evitar mudan\u00e7as de contexto e promover a localidade da cache. Com quatro n\u00facleos, atribuo as m\u00e1scaras de forma a que cada worker receba um n\u00facleo pr\u00f3prio. Em seguida, analiso as taxas de falhas de cache, as lat\u00eancias medianas e os percentis de 99, para observar claramente o efeito. Encontrar\u00e1 explica\u00e7\u00f5es mais detalhadas sobre afinidade e NUMA de forma resumida em <a href=\"https:\/\/webhosting.de\/pt\/servidor-processo-afinidade-numa-sensibilizacao-alojamento-ressourcentuning\/\">Afilia\u00e7\u00e3o da CPU na pr\u00e1tica<\/a>, o que, no ajuste fino de <strong>Trabalhador<\/strong>- Os layouts ajudam.<\/p>\n\n<h2>Planear a capacidade: margem de seguran\u00e7a e testes de carga<\/h2>\n<p>Quando se trata de liga\u00e7\u00f5es, pretendo fazer uma <strong>Tamp\u00e3o<\/strong> que seja significativamente superior aos picos observados, para que os picos de tr\u00e1fego de curta dura\u00e7\u00e3o n\u00e3o ultrapassem diretamente os limites. Se duplicar a carga de pico como ponto de partida, tenho uma margem de manobra s\u00f3lida em muitos cen\u00e1rios. Em caso de tr\u00e1fego altamente vari\u00e1vel, aumentei ainda mais a margem de seguran\u00e7a at\u00e9 que os percentis de 99% se comportassem de forma est\u00e1vel. Em seguida, verifico os pontos de estrangulamento com ferramentas como o wrk ou o k6, observo as taxas de erro e analiso as liga\u00e7\u00f5es abertas no estado. S\u00f3 quando as m\u00e9tricas estiverem consistentes \u00e9 que aumentei ou reduzi de forma espec\u00edfica cada <strong>Valores<\/strong>.<\/p>\n\n<h2>Configura\u00e7\u00e3o e exemplos de c\u00e1lculos<\/h2>\n<p>Calculo a capacidade de liga\u00e7\u00e3o multiplicando o n\u00famero de workers pelo n\u00famero de liga\u00e7\u00f5es por worker e, a partir da\u00ed, defino limites mais elevados. Com quatro n\u00facleos de CPU, a configura\u00e7\u00e3o \u00abauto\u00bb e 4096 liga\u00e7\u00f5es por worker, chego, matematicamente, a 16 384 liga\u00e7\u00f5es simult\u00e2neas. Em cen\u00e1rios de proxy, costumo definir o rlimit_nofile para 32 768 ou mais, de modo a incluir os sockets upstream. Para m\u00e1quinas pequenas com dois n\u00facleos, 2048 liga\u00e7\u00f5es por trabalhador s\u00e3o frequentemente suficientes, desde que a propor\u00e7\u00e3o de uploads e de tr\u00e1fego TLS se mantenha moderada. A tabela seguinte ajuda a classificar os <strong>Valores iniciais<\/strong>:<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>N\u00facleos de CPU<\/th>\n      <th>processos_trabalhadores<\/th>\n      <th>worker_connections (In\u00edcio)<\/th>\n      <th>Valor m\u00ednimo de rlimit_nofile (valor de refer\u00eancia)<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>2<\/td>\n      <td>auto (\u22482)<\/td>\n      <td>2048<\/td>\n      <td>\u2265 4096<\/td>\n      <td><strong>Reserva<\/strong> Planear para TLS\/Proxy<\/td>\n    <\/tr>\n    <tr>\n      <td>4<\/td>\n      <td>auto (\u22484)<\/td>\n      <td>4096<\/td>\n      <td>\u2265 16 384<\/td>\n      <td>No caso do proxy, frequentemente um fator de 2 nos FDs<\/td>\n    <\/tr>\n    <tr>\n      <td>8<\/td>\n      <td>auto (\u22488)<\/td>\n      <td>4096-8192<\/td>\n      <td>\u2265 32 768<\/td>\n      <td><strong>Ensaio de carga<\/strong> decide sobre o aumento<\/td>\n    <\/tr>\n    <tr>\n      <td>16+<\/td>\n      <td>carro, ou menos, se for o caso<\/td>\n      <td>8192+<\/td>\n      <td>\u2265 65535<\/td>\n      <td>Testar com afinidade e discri\u00e7\u00e3o<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_performance_opt_4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NGINX Worker e Upstreams: ponderar corretamente os cen\u00e1rios<\/h2>\n<p>Fa\u00e7o a distin\u00e7\u00e3o entre entrega est\u00e1tica, funcionamento do proxy inverso e carga do gateway de API, porque estes s\u00e3o os <strong>Trabalhador<\/strong>-A configura\u00e7\u00e3o varia consoante as necessidades. Os conte\u00fados est\u00e1ticos consomem menos recursos, enquanto o TLS, a compress\u00e3o e as liga\u00e7\u00f5es upstream exigem mais da CPU e dos FDs. Quanto maiores forem as chaves SSL e quanto mais handshakes houver, mais vantajosa se torna a configura\u00e7\u00e3o \u201eum worker por n\u00facleo\u201c. Uploads de grande dimens\u00e3o deslocam o foco para a E\/S, o que me leva a prestar mais aten\u00e7\u00e3o ao `rlimit_nofile` e aos buffers de rede. Quando se verificam tempos de espera percet\u00edveis na aceita\u00e7\u00e3o ou nas respostas do backend, a vis\u00e3o geral ajuda-me a <a href=\"https:\/\/webhosting.de\/pt\/servidor-web-fila-latencia-tratamento-de-pedidos-fila-do-servidor\/\">Filas de espera e lat\u00eancia<\/a>, para evitar pontos de estrangulamento <strong>direcionado<\/strong> resolver.<\/p>\n\n<h2>Fluxo de trabalho pr\u00e1tico: passo a passo para um servidor mais r\u00e1pido<\/h2>\n<p>Come\u00e7o por fazer um levantamento da situa\u00e7\u00e3o atual de todos os elementos relevantes <strong>Valores<\/strong> No ficheiro nginx.conf, verifico os n\u00facleos da CPU, o ulimit e os par\u00e2metros do kernel. Depois, defino o `worker_processes` para \u00abauto\u00bb, defino o `worker_connections`, por exemplo, para 4096 e aumentei generosamente o `rlimit_nofile`. No bloco \u00abEvents\u00bb, ativo o epoll e o multi_accept e verifico os registos atrav\u00e9s de uma atualiza\u00e7\u00e3o. Seguem-se testes de carga em condi\u00e7\u00f5es reproduz\u00edveis, durante os quais observo os tempos de resposta, as taxas de erro e as liga\u00e7\u00f5es abertas. No ajuste fino, altero sempre apenas uma vari\u00e1vel, documento cada passo e verifico os efeitos nos <strong>M\u00e9tricas<\/strong>.<\/p>\n\n<h2>Ambiente de alojamento: recursos, kernel, rede<\/h2>\n<p>Procurarei garantir que haja <strong>CPU<\/strong>-n\u00facleos, mem\u00f3ria RAM suficiente, SSDs ou NVMe r\u00e1pidos e um kernel Linux atualizado. S\u00f3 assim \u00e9 que o epoll, as pilhas TCP modernas e as funcionalidades de offload \u00fateis funcionam de forma fi\u00e1vel. Ajusto par\u00e2metros de rede como o somaxconn e o tcp_max_syn_backlog de acordo com o n\u00famero pretendido de liga\u00e7\u00f5es, para manter as filas de aceita\u00e7\u00e3o curtas. Um fornecedor com desempenho de E\/S robusto e configura\u00e7\u00e3o do sistema de acesso livre compensa claramente neste contexto. Em compara\u00e7\u00f5es, verifica-se que os servi\u00e7os com <strong>Recursos<\/strong> Aumentar significativamente as capacidades do NGINX.<\/p>\n\n<h2>Estrat\u00e9gia de keepalive: liga\u00e7\u00f5es do cliente e a montante<\/h2>\n<p>Utilizo o Keepalive deliberadamente como um instrumento para gerir a capacidade e a lat\u00eancia. Do lado do cliente, configuro <strong>tempo de espera de keepalive<\/strong> n\u00e3o demasiado elevado, para que os sockets inativos n\u00e3o sejam desnecessariamente <em>liga\u00e7\u00f5es_trabalhadores<\/em> bloquear. Valores entre 10 e 30 s costumam proporcionar-me um bom equil\u00edbrio entre reutiliza\u00e7\u00e3o e consumo de recursos. Com <strong>keepalive_requests<\/strong> Limito o n\u00famero de pedidos por liga\u00e7\u00e3o, para cortar as liga\u00e7\u00f5es de longa dura\u00e7\u00e3o e evitar a sobrecarga de mem\u00f3ria. No lado upstream (proxy inverso), mantenho liga\u00e7\u00f5es persistentes com <strong>keepalive<\/strong> no bloco upstream, de modo a eliminar os handshakes e a configura\u00e7\u00e3o do TCP. Para tal, defino o n\u00famero por backend de forma conservadora, em fun\u00e7\u00e3o da capacidade do backend (<em>max_conns<\/em>), caso contr\u00e1rio, eu pr\u00f3prio crio filas no upstream. Importante: cada socket de keepalive conta como uma liga\u00e7\u00e3o aberta e necessita de FDs; tenho isso em conta em <em>rlimit_nofile<\/em> e o meu planeamento de headroom.<\/p>\n\n<h2>Otimiza\u00e7\u00e3o de listas: reuseport, backlog e estrat\u00e9gia de aceita\u00e7\u00e3o<\/h2>\n<p>Distribuo a carga de aceita\u00e7\u00e3o de forma uniforme, ao <strong>SO_REUSEPORT<\/strong> ativar (listar \u2026 reuseport). Cada worker disp\u00f5e assim da sua pr\u00f3pria fila de aceita\u00e7\u00e3o, o que reduz os \u201ethundering herds\u201c e evita pontos de congestionamento. Em combina\u00e7\u00e3o com <strong>multi_accept<\/strong> acelero sensivelmente a fase de aceita\u00e7\u00e3o. A lista de<strong>atraso<\/strong> (listen \u2026 backlog=) e os par\u00e2metros correspondentes do kernel (somaxconn, tcp_max_syn_backlog) defino-os com uma margem generosa, para que os picos n\u00e3o se percam na entrada do socket. A op\u00e7\u00e3o <strong>diferido<\/strong> adiar o `Accept` at\u00e9 que os dados estejam dispon\u00edveis \u2013 no caso de muitas solicita\u00e7\u00f5es de curta dura\u00e7\u00e3o, isso pode ajudar; caso contr\u00e1rio, comparo nos testes. Se eu <strong>accept_mutex<\/strong> O que preciso, determino no benchmark: com o reuseport, na maioria das vezes \u00e9 dispens\u00e1vel; sem o reuseport, pode melhorar a equidade, mas implica um esfor\u00e7o de coordena\u00e7\u00e3o. Aqui, tomo decis\u00f5es com base nos dados, nunca por intui\u00e7\u00e3o.<\/p>\n\n<h2>Configurar os tempos limite e as filas de forma est\u00e1vel<\/h2>\n<p>Eu fixo <strong>Intervalos<\/strong> de forma a que os clientes mais lentos n\u00e3o sobrecarreguem os workers: <em>client_header_timeout<\/em> e <em>tempo limite do corpo do cliente<\/em> Considero-o suficientemente conciso para evitar travamentos, mas suficientemente abrangente para os utilizadores reais. <em>tempo_limite_de_envio<\/em> protege contra respostas bloqueadas destinadas ao cliente. No contexto do proxy, defino <em>tempo limite de liga\u00e7\u00e3o do proxy<\/em>, <em>tempo_limite_de_leitura_proxy<\/em> e <em>proxy_send_timeout<\/em> rigoroso, para que os back-ends em espera n\u00e3o paralisem o front-end. No caso de back-ends com paralelismo limitado, utilizo <strong>fila<\/strong> no bloco upstream com um tempo de espera, para atenuar picos de tr\u00e1fego e sinalizar o erro 503 de forma controlada, em vez de vincular todos os workers a sockets upstream em espera. Al\u00e9m disso, estabilizo com <strong>limite_req<\/strong> (Burst\/Delay) e <strong>limite_conex\u00e3o<\/strong> caminhos sens\u00edveis, para que os clientes ou bots individuais n\u00e3o consumam recursos de forma desproporcionada.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_worker_performance_8392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Buffering, sendfile e AIO: escolher deliberadamente os m\u00e9todos de E\/S<\/h2>\n<p>Eu fixo <strong>sendfile<\/strong> para ficheiros est\u00e1ticos e combina-o com <em>tcp_nopush<\/em>\/<em>tcp_nodelay<\/em> dependendo da carga de trabalho, para agrupar pacotes de forma eficiente ou reduzir as lat\u00eancias interativas. Para ficheiros grandes, utilizo <strong>dire\u00e7\u00e3o<\/strong> a partir de um determinado limiar, para evitar a polui\u00e7\u00e3o da cache e para que a cache de p\u00e1ginas n\u00e3o seja substitu\u00edda. No modo proxy, sou eu que decido se <strong>proxy_buffering<\/strong> ajuda (transfer\u00eancia r\u00e1pida para o cliente, leitura upstream desacoplada) ou se, no caso de cargas de streaming, \u00e9 prefer\u00edvel que eu <em>proxy_request_buffering<\/em> reduza, para iniciar os uploads antecipadamente. Os tamanhos de <em>proxy_buffers<\/em>, <em>proxy_buffer_size<\/em> e <em>buffers_de_cabe\u00e7alho_de_cliente_grandes<\/em> controlo isso de forma consciente, para que o consumo de mem\u00f3ria por liga\u00e7\u00e3o n\u00e3o dispare. Para um acesso aos ficheiros que n\u00e3o sobrecarregue a CPU, estou a considerar <strong>aio<\/strong> (nativo ou threads), mas faz testes exaustivos, porque as caracter\u00edsticas do ciclo de eventos e das E\/S influenciam-se mutuamente.<\/p>\n\n<h2>HTTP\/2\/HTTP\/3 e TLS: impacto na capacidade dos workers<\/h2>\n<p>Tenho em conta que <strong>HTTP\/2<\/strong> e <strong>HTTP\/3<\/strong> Alterar a din\u00e2mica das liga\u00e7\u00f5es: Muitas solicita\u00e7\u00f5es s\u00e3o executadas como <em>Streams<\/em> atrav\u00e9s de um n\u00famero reduzido de liga\u00e7\u00f5es TCP ou QUIC. Isto reduz o n\u00famero de liga\u00e7\u00f5es, mas aumenta os requisitos de CPU e mem\u00f3ria por liga\u00e7\u00e3o (multiplexa\u00e7\u00e3o, compress\u00e3o de cabe\u00e7alhos, TLS\/QUIC). A minha <em>liga\u00e7\u00f5es_trabalhadores<\/em> Por isso, n\u00e3o interpreto isso cegamente como \u201eo mesmo n\u00famero de pedidos\u201c. Observo <em>fluxos simult\u00e2neos<\/em> por liga\u00e7\u00e3o e por pe\u00e7a <em>tempo de espera de keepalive<\/em> e, se necess\u00e1rio,. <em>http2_max_concurrent_streams<\/em> . No que diz respeito ao TLS, ganho com a retomada de sess\u00e3o (tickets\/cache) e o OCSP Stapling; assim, evito handshakes dispendiosos e mantenho as lat\u00eancias baixas. O reverso da medalha: os keepalives mais longos ocupam FDs e RAM \u2013 por isso, planeio <em>rlimit_nofile<\/em> e quotas de mem\u00f3ria com reservas realistas. Para algoritmos de encripta\u00e7\u00e3o que exigem muito da CPU, vale a pena testar a afinidade e a acelera\u00e7\u00e3o criptogr\u00e1fica moderna.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-optimaler-setup-9182.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoriza\u00e7\u00e3o: estado, registos e m\u00e9tricas<\/h2>\n<p>Consigo garantir a transpar\u00eancia com um sistema simplificado <strong>Estado<\/strong>-Endpoint (por exemplo, stub_status), para ver as liga\u00e7\u00f5es ativas, os estados de leitura\/grava\u00e7\u00e3o\/espera e os pedidos aceites. Nos registos, procuro manter o ru\u00eddo ao m\u00ednimo: um registo compacto <em>log_format<\/em> com a hora, o estado, os tempos de upstream e os bytes \u00e9 suficiente para a maioria das an\u00e1lises. Em caso de QPS muito elevado, desativo o registo de acesso de forma seletiva (com base na localiza\u00e7\u00e3o) ou armazeno os registos em buffer de forma ass\u00edncrona, para que a E\/S n\u00e3o cause atrasos. Defino o registo de erros para <em>avisar<\/em> ou <em>erro<\/em> e, apenas para an\u00e1lises espec\u00edficas, mude temporariamente para <em>depurar<\/em>. Correlaciono continuamente as lat\u00eancias (mediana\/95.\u00ba\/99.\u00ba percentil), as liga\u00e7\u00f5es abertas, as taxas de erro do backend e a carga da CPU por worker \u2013 a partir da\u00ed, deduzo ajustes nas tr\u00eas diretivas-chave e deteto atempadamente efeitos de satura\u00e7\u00e3o.<\/p>\n\n<h2>Contentores e ambientes virtuais: passar os limites de forma clara<\/h2>\n<p>Estou a verificar, em contentores, os <strong>cgroup<\/strong>-Defina os limites para a CPU, a RAM e os PIDs e ajuste-os de acordo com as configura\u00e7\u00f5es do NGINX. <em>ulimit -n<\/em> tem de ser suficientemente elevado dentro do contentor, caso contr\u00e1rio, os meus ajustes no rlimit_nofile perdem o efeito. No caso de quotas de CPU (por exemplo, 2 vCPUs), defino <em>processos_trabalhadores<\/em> Consequentemente, para que a programa\u00e7\u00e3o n\u00e3o force artificialmente o tr\u00e1fego. Perto da rede, beneficio de uma menor lat\u00eancia de overhead nos modos de rede \u201ehost\u201c, enquanto as sobreposi\u00e7\u00f5es implicam saltos adicionais. Em hosts Multi-NUMA, presto aten\u00e7\u00e3o \u00e0 afinidade e aos soquetes de mem\u00f3ria, para que os workers n\u00e3o operem em n\u00f3s diferentes. O mesmo se aplica \u00e0 afinidade de IRQ e RPS\/XPS: se os caminhos desde a NIC, passando pela IRQ, at\u00e9 ao n\u00facleo do worker estiverem corretos, os picos de lat\u00eancia diminuem de forma mensur\u00e1vel.<\/p>\n\n<h2>Ciclo de vida da liga\u00e7\u00e3o: portas ef\u00e9meras, TIME_WAIT e reservas<\/h2>\n<p>Tenho a inten\u00e7\u00e3o de... <strong>Portas ef\u00e9meras<\/strong> (ip_local_port_range), quando o NGINX atua como cliente ativo em rela\u00e7\u00e3o aos servidores upstream. Em caso de um d\u00e9bito de liga\u00e7\u00f5es muito elevado, evito a flutua\u00e7\u00e3o excessiva de portas atrav\u00e9s do \u201eUpstream-Keepalive\u201c, o que reduz as pilhas de TIME_WAIT. Recorro \u00e0s op\u00e7\u00f5es do kernel para \u00abReuse\u00bb apenas com cautela; as pilhas modernas j\u00e1 otimizam grande parte do processo internamente. \u00c9 mais est\u00e1vel controlar a dura\u00e7\u00e3o das liga\u00e7\u00f5es atrav\u00e9s de valores adequados de keepalive e timeout e <em>reutiliza\u00e7\u00e3o<\/em> para garantir uma distribui\u00e7\u00e3o justa. No c\u00e1lculo da capacidade, al\u00e9m dos clientes, tenho sempre em conta o lado a montante \u2013 muitas vezes, s\u00e3o os FD que constituem o verdadeiro fator limitante, e n\u00e3o a porta de entrada.<\/p>\n\n<h2>Reinicializa\u00e7\u00f5es e implementa\u00e7\u00f5es suaves, sem interrup\u00e7\u00f5es<\/h2>\n<p>Utilizo o modelo Master\/Worker para <strong>recarregamentos suaves<\/strong>: O Master carrega novas configura\u00e7\u00f5es; os antigos Workers s\u00e3o desativados, enquanto os novos assumem o funcionamento de forma cont\u00ednua. Com <em>worker_shutdown_timeout<\/em> Dou tempo \u00e0s solicita\u00e7\u00f5es para terminarem corretamente, sem bloquear recursos. As implementa\u00e7\u00f5es sem tempo de inatividade no upstream associo-as a verifica\u00e7\u00f5es de integridade e <em>proxy_next_upstream<\/em>-Regras para garantir que os backends com falhas n\u00e3o aumentem a lat\u00eancia global. Quando fa\u00e7o altera\u00e7\u00f5es na configura\u00e7\u00e3o, altero sempre apenas um par\u00e2metro e verifico os efeitos nos registos e nas m\u00e9tricas \u2013 assim, evito erros decorrentes de confus\u00e3o e mantenho o desempenho reprodut\u00edvel.<\/p>\n\n<h2>Resumo conciso<\/h2>\n<p>Estou a ligar <strong>processos_trabalhadores<\/strong> Defina o n\u00famero de n\u00facleos (idealmente em modo autom\u00e1tico), ajuste o `worker_connections` de acordo com a carga de pico e aumente generosamente o `rlimit_nofile`, juntamente com os limites do sistema operativo. No bloco de eventos, utilizo o `epoll` e o `multi_accept`, verifico tudo com testes de carga reproduz\u00edveis e, em seguida, fa\u00e7o ajustes em pequenos passos. Para cargas de trabalho de proxy, prevejo descritores adicionais e testo a afinidade da CPU quando as cargas de trabalho s\u00e3o constantes. Uma pilha bem configurada, com um kernel adequado, E\/S r\u00e1pida e par\u00e2metros de rede sensatos, faz toda a diferen\u00e7a. \u00c9 assim que consigo <strong>NGINX<\/strong> confi\u00e1vel no que diz respeito ao desempenho exigido pelas p\u00e1ginas e APIs mais exigentes.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubra como configurar corretamente os processos de trabalho do NGINX e melhorar significativamente o desempenho do servidor web atrav\u00e9s de um ajuste espec\u00edfico do NGINX.<\/p>","protected":false},"author":1,"featured_media":20707,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20714","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"129","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"NGINX Worker","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20707","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20714","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=20714"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20714\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20707"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20714"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20714"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20714"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}