Diretivas essenciais do Nginx: eventos, HTTP e fundamentos de desempenho seguro

Este capítulo foca nas diretivas que aparecem com frequência em configurações reais e que afetam diretamente desempenho, consumo de recursos e comportamento de rede. A ideia é entender o que cada uma faz, quando mexer e como ajustar com segurança em ambientes pequenos.

Bloco events: concorrência e limites de conexões

worker_processes (conceito)

worker_processes define quantos processos “workers” o Nginx cria para atender requisições. Cada worker é um processo do sistema operacional que aceita conexões e processa tráfego. Em geral, mais workers permitem usar melhor múltiplos núcleos de CPU, mas também aumentam consumo de memória e podem aumentar contenção em cenários específicos.

• Regra prática: em servidores comuns, worker_processes auto; é uma escolha segura e costuma ser o padrão recomendado, pois ajusta ao número de CPUs disponíveis.
• Quando ajustar com cautela: ambientes com limites rígidos de CPU (containers com cgroup), hosts muito pequenos (1 vCPU) ou quando você quer previsibilidade absoluta. Nesses casos, fixar em 1 ou 2 pode ser mais simples para observar comportamento.

worker_connections

worker_connections define quantas conexões simultâneas cada worker pode manter abertas. O limite total teórico de conexões do Nginx fica próximo de:

conexoes_maximas ~= worker_processes * worker_connections

Na prática, esse número é limitado também por recursos do sistema (principalmente ulimit -n, que define quantos descritores de arquivo o processo pode abrir) e por conexões “internas” (por exemplo, ao usar proxy, uma requisição pode consumir uma conexão de entrada e outra de saída).

Impacto em ambientes pequenos: se você tem um VPS pequeno e define worker_connections muito baixo, pode ver erros de saturação sob picos (clientes não conseguem conectar). Se define alto demais sem ajustar limites do sistema, pode achar que “aumentou capacidade”, mas na verdade o Nginx vai bater em limites do SO e falhar de outras formas.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

Exemplo de bloco events seguro e comum

worker_processes auto;  # normalmente pode ficar assim (ajuste com cautela apenas se necessário)  events {     worker_connections 1024;  # bom ponto de partida para ambientes pequenos/médios } 

O que ajustar com cautela: worker_processes e worker_connections devem ser ajustados em conjunto com limites do sistema. Se você aumentar worker_connections, verifique também o limite de arquivos abertos do serviço (ex.: ulimit -n e configurações do systemd).

Bloco http: envio de arquivos, TCP e conexões persistentes

sendfile

sendfile on; habilita um caminho de envio de arquivos mais eficiente no kernel, reduzindo cópias de dados entre espaço de usuário e kernel. Isso costuma melhorar desempenho ao servir arquivos estáticos (imagens, CSS, JS, downloads).

• Quando ajuda: sites com conteúdo estático e tráfego moderado/alto.
• Quando observar com atenção: se você usa sistemas de arquivos de rede ou cenários com cache/proxy muito específicos, pode haver efeitos inesperados. Em servidores comuns com disco local, é normalmente benéfico.

tcp_nopush e tcp_nodelay

Essas diretivas influenciam como o Nginx agrupa e envia pacotes TCP, afetando latência e eficiência.

• tcp_nopush on; (em conjunto com sendfile on) tende a enviar cabeçalhos HTTP e o início do corpo de forma mais “coesa”, reduzindo pacotes pequenos e melhorando eficiência em respostas maiores.
• tcp_nodelay on; reduz atrasos para enviar pequenos pacotes em conexões keepalive, melhorando latência percebida em respostas pequenas e interativas.

Combinação comum: sendfile on; + tcp_nopush on; + tcp_nodelay on;. Não é uma “bala de prata”, mas é uma base amplamente usada.

keepalive_timeout e conexões persistentes (impacto prático)

HTTP keepalive permite que o cliente reutilize a mesma conexão TCP para múltiplas requisições, evitando o custo de abrir/fechar conexões repetidamente. Isso reduz latência e CPU, especialmente para páginas que carregam vários recursos (CSS, JS, imagens).

Por outro lado, conexões keepalive ficam abertas por um tempo ocioso, consumindo recursos (descritores de arquivo e memória). Em ambientes pequenos, isso pode ser o fator que limita conexões simultâneas.

Impacto prático em um servidor pequeno (exemplo mental):

• Suponha worker_processes auto em 1 vCPU (na prática, 1 worker) e worker_connections 1024.
• Se muitos clientes mantêm conexões ociosas por 60s, você pode “encher” o limite de conexões com clientes parados, reduzindo capacidade de aceitar novos clientes durante picos.
• Se reduzir keepalive_timeout para 10–15s, você libera conexões mais rápido, o que pode melhorar robustez sob picos, com pequeno custo de mais handshakes TCP.

Regra prática:

• Ambiente pequeno (pouca RAM/CPU, tráfego variável): keepalive_timeout 10s; a 15s costuma ser um bom começo.
• Ambiente com tráfego estável e foco em latência: valores maiores podem fazer sentido, mas devem ser testados observando conexões ativas e consumo.

Tipos MIME: include mime.types e default_type

O tipo MIME informa ao navegador como interpretar o conteúdo (HTML, CSS, JS, imagens, etc.). O Nginx normalmente mapeia extensões de arquivo para tipos MIME via um arquivo de tabela.

• include mime.types; carrega a lista de mapeamentos (por exemplo, .css → text/css, .js → application/javascript).
• default_type define o tipo MIME usado quando o Nginx não consegue determinar o tipo pelo mapeamento.

Por que isso importa:

• Se default_type for inadequado, arquivos sem extensão ou não mapeados podem ser interpretados de forma errada pelo cliente.
• Uma base comum é default_type application/octet-stream;, que é um tipo genérico para “dados binários” e evita que o navegador tente interpretar conteúdo desconhecido como texto/HTML.

Configuração base de http segura e legível (modelo)

Abaixo está um modelo de base para o bloco http focado em desempenho seguro e previsível. Ele não substitui configurações de TLS, logs, compressão ou reverse proxy (que podem ser tratados em capítulos específicos), mas estabelece um núcleo sólido.

http {     # Tipos MIME (normalmente pode manter padrão)     include       mime.types;     default_type  application/octet-stream;      # Envio eficiente de arquivos estáticos     sendfile        on;     tcp_nopush      on;     tcp_nodelay     on;      # Conexões persistentes (ajuste com cautela)     keepalive_timeout 15s;      # Segurança básica de parsing     server_tokens off;      # Tamanhos e buffers: mantenha padrão a menos que tenha motivo e métricas     # client_body_buffer_size, client_header_buffer_size, large_client_header_buffers etc.      # Inclua configurações de servidores virtuais (vhosts) em arquivos separados     # (a organização em includes já foi tratada em outro capítulo)     # include /etc/nginx/conf.d/*.conf;     # include /etc/nginx/sites-enabled/*; }

O que pode permanecer padrão na maioria dos casos

• include mime.types; e default_type application/octet-stream;
• sendfile on;, tcp_nopush on;, tcp_nodelay on; (base comum e segura)
• worker_processes auto; (na maioria dos hosts)

O que ajustar com cautela (e por quê)

• worker_connections: aumentar sem ajustar limites do SO pode causar falhas por falta de descritores de arquivo.
• keepalive_timeout: alto demais pode “prender” conexões ociosas e reduzir capacidade em picos; baixo demais pode aumentar overhead de novas conexões.
• default_type: mudar para text/plain ou text/html pode causar interpretações inesperadas de arquivos desconhecidos; mantenha genérico.

Passo a passo: leitura e ajuste controlado (sem adivinhar)

1) Identifique as diretivas atuais

Abra o arquivo principal e procure por worker_processes, bloco events e bloco http. Localize especificamente: worker_connections, sendfile, tcp_nopush, tcp_nodelay, keepalive_timeout, include mime.types e default_type.

2) Estabeleça um ponto de partida conservador

Se a configuração estiver muito diferente e você não tiver métricas, use valores conservadores:

• worker_processes auto;
• worker_connections 1024;
• keepalive_timeout 15s;
• sendfile on;, tcp_nopush on;, tcp_nodelay on;
• include mime.types; e default_type application/octet-stream;

3) Faça uma alteração por vez

Escolha apenas uma diretiva para alterar (por exemplo, keepalive_timeout de 15s para 10s). Evite mudar várias ao mesmo tempo, para não perder a relação causa/efeito.

4) Valide e recarregue com segurança

Antes de aplicar, valide a sintaxe. Em seguida, recarregue para evitar downtime (quando possível).

# validar sintaxe (caminho pode variar) nginx -t  # recarregar (sem derrubar conexões ativas, quando suportado) nginx -s reload

5) Observe sinais básicos de capacidade

Mesmo sem ferramentas avançadas, você pode observar:

• Se há erros de conexão recusada durante picos (sugere limite de conexões/recursos).
• Se o servidor fica com muitas conexões ociosas por longos períodos (sugere keepalive alto para o perfil de tráfego).
• Se servir estáticos está “pesado” (sendfile/tcp_* podem ajudar, mas também verifique cache e disco).

Exercícios práticos (leitura e ajuste controlado)

Exercício 1: calcule o teto teórico de conexões

• Encontre worker_processes e worker_connections.
• Calcule worker_processes * worker_connections.
• Anote: você usa proxy/reverse proxy? Se sim, considere que uma requisição pode consumir conexões adicionais.

Exercício 2: ajuste de keepalive para ambiente pequeno

• Defina keepalive_timeout 15s;.
• Recarregue.
• Depois reduza para 10s e compare: em picos, o servidor parece aceitar novas conexões com mais facilidade? Há impacto perceptível de latência?

Exercício 3: verifique MIME e comportamento de default_type

• Confirme que include mime.types; está ativo.
• Confirme que default_type está como application/octet-stream.
• Crie um arquivo estático sem extensão (por exemplo, arquivo) e sirva-o. Observe o Content-Type retornado. O objetivo é entender o fallback e evitar suposições perigosas.

Exercício 4: ajuste controlado de worker_connections com atenção ao SO

• Aumente worker_connections de 1024 para 2048.
• Valide e recarregue.
• Se houver falhas ao subir carga, investigue limites de descritores de arquivo do serviço. O objetivo é perceber que “aumentar no Nginx” não basta se o sistema não acompanhar.

Exercício 5: compare envio de estáticos com e sem sendfile

• Em um ambiente de teste, alterne sendfile on; e sendfile off;.
• Sirva um arquivo grande (por exemplo, alguns MB) e observe consumo de CPU e tempo de resposta. O objetivo é entender o ganho típico do caminho otimizado.