Otimização de Desempenho do Nginx: Dicas para Sites Mais Rápidos

Sites lentos geralmente vêm de um punhado de causas: respostas upstream caras, cabeçalhos de cache ausentes, ativos superdimensionados, trabalhadores bloqueados ou um servidor ajustado para padrões em vez do seu tráfego. A otimização de desempenho do Nginx funciona melhor quando você mede primeiro, altera uma configuração de cada vez e mantém a configuração legível.

Use os exemplos abaixo como pontos de partida e, em seguida, teste-os contra seu próprio aplicativo. Um servidor de arquivos estáticos, um site WordPress/PHP-FPM e um proxy reverso de API precisam de diferentes compensações.

Entendendo os Gargalos de Desempenho do Nginx

Comece encontrando o gargalo. As causas comuns incluem:

Uso de CPU: A alta carga da CPU retarda o tratamento de solicitações, a compressão e o trabalho TLS.
Pressão de memória: A troca (swapping) prejudica seriamente a latência.
I/O de rede: Links lentos, janelas upstream pequenas ou perda de pacotes podem dominar o tempo de resposta.
I/O de disco: Arquivos estáticos, arquivos de cache e logs ainda tocam no armazenamento.
Latência upstream: O Nginx pode ser rápido enquanto seu servidor de aplicativos é lento.

Ferramentas como top, htop, iostat, ss, logs de acesso e o módulo stub_status do Nginx podem ajudá-lo a decidir o que ajustar.

Técnicas Principais de Otimização do Nginx

Processos de Trabalho e Conexões

A diretiva worker_processes controla quantos processos de trabalho o Nginx inicia. auto é um padrão prático porque o Nginx detecta os núcleos de CPU disponíveis.

# Define worker_processes para o número de núcleos de CPU
worker_processes auto;

Dentro de cada processo de trabalho, worker_connections limita quantas conexões simultâneas esse trabalhador pode abrir. O limite superior aproximado é worker_processes * worker_connections, mas a capacidade real também depende de conexões upstream, limites de arquivos abertos, comportamento keep-alive e limites do sistema operacional.

# Aumente worker_connections para sites de alto tráfego
worker_connections 1024;

Se você vir Too many open files, aumentar worker_connections sozinho não é suficiente. Verifique também o limite de descritores de arquivo do serviço, geralmente controlado pelo LimitNOFILE do systemd ou limites do shell.

Estratégias de Cache

O cache geralmente é a otimização de desempenho do Nginx de maior impacto porque evita trabalho repetido.

Cache do Navegador

Diga aos navegadores para armazenar em cache ativos estáticos com versão, como imagens, CSS e JavaScript. Use longos tempos de vida somente quando os nomes dos arquivos mudam na implantação, como app.8f3c1.css.

location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
    add_header Cache-Control "public";
}

Cache de Proxy

Se o Nginx for um proxy reverso, ele pode armazenar em cache respostas selecionadas do backend. Isso funciona bem para páginas públicas, respostas de API com regras de atualização claras e páginas caras que não variam por usuário.

Primeiro, defina uma zona de cache no bloco http:

http {
    # ... outras configurações http ...
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;
    # ...
}

/var/cache/nginx: O diretório onde os arquivos de cache serão armazenados.
levels=1:2: Define a estrutura de diretórios para o cache.
keys_zone=my_cache:10m: Cria uma zona de memória compartilhada chamada my_cache com 10MB para armazenar chaves de cache.
max_size=1g: Define o tamanho máximo do cache.
inactive=60m: Remove entradas de cache que não foram acessadas por 60 minutos.

Em seguida, habilite o cache no seu bloco location:

location / {
    proxy_pass http://your_backend_app;
    proxy_cache my_cache;
    proxy_cache_valid 200 302 10m; # Cache de respostas 200 e 302 por 10 minutos
    proxy_cache_valid 404 1m;     # Cache de respostas 404 por 1 minuto
    add_header X-Cache-Status $upstream_cache_status;
}

add_header X-Cache-Status $upstream_cache_status; é útil para depuração, mostrando se uma solicitação foi um acerto de cache, erro ou bypass.

Não armazene em cache páginas personalizadas, a menos que sua chave de cache considere os dados que alteram a resposta. Por exemplo, um painel de controle logado geralmente deve ignorar o cache de proxy, enquanto /assets/logo.png pode ser armazenado em cache por um longo tempo.

Compressão

A compressão reduz o tamanho da transferência para respostas baseadas em texto, como HTML, CSS, JavaScript, JSON e XML. Não ajuda muito para arquivos já compactados, como JPEG, PNG, MP4 ou muitos formatos de arquivo.

http {
    # ...
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    # ...
}

gzip on;: Habilita a compressão Gzip.
gzip_vary on;: Adiciona o cabeçalho Vary: Accept-Encoding, que é importante para proxies de cache.
gzip_proxied any;: Comprime respostas para solicitações de proxy também.
gzip_comp_level 6;: Define o nível de compressão (1-9, maior significa melhor compressão, mas mais CPU).
gzip_types ...;: Especifica os tipos MIME a serem compactados.

O Brotli pode compactar bem ativos de texto, mas as compilações padrão do Nginx de código aberto nem todas vêm com suporte a Brotli. Verifique seu pacote ou conjunto de módulos antes de adicionar diretivas Brotli.

Gerenciamento de Conexões e Keep-Alive

A diretiva keepalive_timeout controla por quanto tempo uma conexão de cliente ociosa permanece aberta. Reutilizar uma conexão evita handshakes extras de TCP e TLS, mas conexões ociosas ainda consomem recursos.

http {
    # ...
    keepalive_timeout 65;
    keepalive_requests 1000;
    # ...
}

keepalive_timeout 65;: Define o tempo limite keep-alive para 65 segundos.
keepalive_requests 1000;: Define o número máximo de solicitações que podem ser feitas em uma única conexão keep-alive.

Para APIs com muitas solicitações curtas, o keep-alive ajuda. Para um servidor pequeno com muitos clientes ociosos, um tempo limite mais curto pode ser melhor.

Buffering e Limites de Tamanho de Solicitação

O Nginx usa buffers para corpos de cliente e respostas de proxy. Os padrões são bons para muitos sites, mas aplicativos com muitos uploads e cabeçalhos upstream grandes podem precisar de configurações explícitas.

http {
    # ...
    client_body_buffer_size 10K;
    client_max_body_size 8M;
    proxy_buffers 8 16k;
    proxy_buffer_size 16k;
    proxy_connect_timeout 60;
    proxy_send_timeout 60;
    proxy_read_timeout 60;
    # ...
}

client_body_buffer_size: Tamanho do buffer usado para ler o corpo da solicitação do cliente.
client_max_body_size: Tamanho máximo permitido do corpo da solicitação do cliente.
proxy_buffers, proxy_buffer_size: Controlam o buffering quando o Nginx atua como proxy.

Evite copiar trechos de buffer cegamente. Se você vir upstream sent too big header, investigue os cabeçalhos upstream antes de aumentar proxy_buffer_size. Se os uploads falharem com 413 Request Entity Too Large, defina client_max_body_size para o tamanho que seu aplicativo realmente suporta.

Otimização TLS

Para sites HTTPS, as configurações TLS afetam tanto a latência quanto a segurança.

Retomada de sessão: Use um cache de sessão para acelerar conexões repetidas.

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;

Versões TLS: Habilite TLS 1.2 e TLS 1.3, a menos que seus requisitos de compatibilidade digam o contrário.
OCSP stapling: Pode reduzir viagens de ida e volta de validação de certificado quando sua cadeia de certificados suporta.
```
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
```

Servindo Arquivos Estáticos

O Nginx é forte em servir arquivos estáticos. Essas diretivas são comuns no bloco http:

sendfile: Permite que o kernel copie dados de arquivo diretamente para o soquete em sistemas suportados.
```
sendfile on;
```
tcp_nopush e tcp_nodelay: Ajustam o comportamento de envio de pacotes para cargas de trabalho HTTP comuns.
```
tcp_nopush on;
tcp_nodelay on;
```

Monitoramento e Testes

Após cada alteração, teste e compare. Ferramentas úteis incluem:

Nginx stub_status: Conexões ativas, conexões aceitas, conexões tratadas e solicitações.
top/htop: Pressão de CPU e memória.
iostat: I/O de disco.
WebPageTest ou PageSpeed Insights: Desempenho no lado do navegador.
wrk, ab ou hey: Testes de carga locais contra endpoints controlados.

Mantenha uma cópia da configuração anterior, execute sudo nginx -t, recarregue e compare latência, taxa de erro, CPU e tempo de resposta upstream. A melhor otimização de desempenho do Nginx é aquela que suas medições podem provar.

Conclusão Prática

Comece com a medição, depois corrija o maior gargalo primeiro. Para a maioria dos sites, isso significa definir limites de trabalho sensatos, adicionar cache do navegador para ativos estáticos, habilitar gzip, armazenar em cache respostas upstream seguras e observar os logs após cada recarga.