Lista Essencial de Ajustes de Desempenho do Nginx para Sites de Alto Tráfego

O ajuste de desempenho do Nginx é mais fácil quando você o trata como uma lista de verificação, não como um jogo de adivinhação. Comece com os limites que decidem quanto tráfego o Nginx pode aceitar, depois vá para buffering, cache, compressão, registro em log, timeouts, TLS e os serviços de backend por trás dele.

Não cole todas as diretivas aqui na produção de uma só vez. Uma boa lista de verificação de ajuste de desempenho do Nginx ajuda você a decidir o que verificar, por que é importante e o que pode dar errado se você exagerar. A configuração correta para um site de documentação principalmente estático não é a configuração correta para uma API de long-polling ou um serviço de upload de arquivos.

1. Otimize Processos Workers e Conexões

O Nginx aproveita um modelo de processo mestre-worker. O processo mestre lê a configuração e gerencia os processos workers, que lidam com as requisições reais dos clientes. Configurá-los adequadamente pode melhorar drasticamente a concorrência e a utilização de recursos.

worker_processes

Esta diretiva determina quantos processos workers o Nginx irá gerar. Geralmente, defini-lo como auto permite que o Nginx detecte o número de núcleos de CPU e gere um número igual de processos workers, o que é uma prática recomendada comum.

worker_connections

Define o número máximo de conexões simultâneas que um único processo worker pode abrir. Esta configuração, em conjunto com worker_processes, determina o total teórico de conexões simultâneas que o Nginx pode manipular (worker_processes * worker_connections).

multi_accept

Permite que um processo worker aceite múltiplas novas conexões de uma só vez, evitando possíveis gargalos sob alta carga.

# /etc/nginx/nginx.conf

worker_processes auto; # Geralmente definido como 'auto' ou o número de núcleos de CPU

events {
    worker_connections 1024; # Ajuste com base na capacidade do servidor e na carga esperada
    multi_accept on;
}

Dica: Se a CPU estiver consistentemente alta, aumentar worker_connections não resolverá o problema por si só. Primeiro, confirme se a CPU está vindo de handshakes TLS, compressão, registro em log, roteamento pesado de regex ou da aplicação upstream.

2. Gerenciamento Eficiente de Conexões

Otimizar como o Nginx lida com conexões de rede pode reduzir a sobrecarga e melhorar a capacidade de resposta.

keepalive_timeout

Especifica por quanto tempo uma conexão keep-alive do cliente permanecerá aberta. Reutilizar conexões reduz a sobrecarga de estabelecer novas conexões TCP e handshakes SSL. Um valor comum é de 15 a 65 segundos, dependendo da interatividade da sua aplicação.

sendfile

Habilita a transferência direta de dados entre descritores de arquivo, ignorando o buffer do espaço do usuário. Isso melhora significativamente o desempenho ao servir arquivos estáticos.

tcp_nopush

Funciona com sendfile. O Nginx tenta enviar o cabeçalho HTTP e o início do arquivo em um único pacote. Depois disso, ele envia dados em pacotes completos. Isso reduz o número de pacotes enviados.

tcp_nodelay

Instrui o Nginx a enviar dados assim que estiverem disponíveis, sem fazer buffer. Isso é benéfico para aplicações interativas onde a baixa latência é mais crítica do que maximizar a taxa de transferência (por exemplo, aplicações de chat ou atualizações em tempo real).

http {
    keepalive_timeout 65; # Conexões keep-alive por 65 segundos
    sendfile on;
    tcp_nopush on; # Requer sendfile ativado
    tcp_nodelay on; # Útil para proxy de conteúdo dinâmico
}

3. Otimização de Buffer

O Nginx usa buffers para lidar com requisições de clientes e respostas de servidores upstream (como servidores de aplicação). Dimensionar adequadamente esses buffers pode evitar E/S de disco desnecessária, reduzir o uso de memória e melhorar a taxa de transferência.

Buffers do Cliente

• client_body_buffer_size: Tamanho do buffer para o corpo da requisição do cliente. Se um corpo exceder isso, ele é escrito em um arquivo temporário.
• client_header_buffer_size: Tamanho do buffer para a primeira linha e cabeçalhos de uma requisição do cliente.
• large_client_header_buffers: Define o número e o tamanho de buffers maiores para ler cabeçalhos de requisição do cliente. Útil para requisições com muitos cookies ou cabeçalhos referer longos.

Buffers de Proxy (para configurações de proxy reverso)

• proxy_buffers: O número e o tamanho dos buffers usados para ler respostas do servidor proxy.
• proxy_buffer_size: O tamanho do primeiro buffer para ler a resposta. Geralmente menor, pois geralmente contém apenas cabeçalhos.
• proxy_busy_buffers_size: A quantidade máxima de buffers de resposta que podem estar no estado 'ocupado' (sendo ativamente enviados ao cliente) a qualquer momento.

Buffers FastCGI (para PHP-FPM, etc.)

• fastcgi_buffers: O número e o tamanho dos buffers usados para ler respostas do servidor FastCGI.
• fastcgi_buffer_size: O tamanho do primeiro buffer para ler a resposta.

http {
    # Buffers do Cliente
    client_body_buffer_size 1M; # Ajuste com base no tamanho esperado do corpo da requisição (por exemplo, uploads de arquivos)
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k; # 4 buffers, cada um com 8KB

    # Buffers de Proxy (se o Nginx atuar como proxy reverso)
    proxy_buffers 8 16k; # 8 buffers, cada um com 16KB
    proxy_buffer_size 16k; # Primeiro buffer com 16KB
    proxy_busy_buffers_size 16k; # Máx. 16KB de buffers ocupados

    # Buffers FastCGI (se o Nginx trabalhar com PHP-FPM)
    fastcgi_buffers 16 16k; # Ponto de partida para muitas aplicações PHP-FPM
    fastcgi_buffer_size 16k; # Primeiro buffer com 16KB
}

Aviso: Definir buffers muito pequenos pode levar a E/S de disco e degradação de desempenho. Definir buffers muito grandes pode consumir memória excessiva. Encontre um equilíbrio através de testes.

4. Implemente Estratégias Robustas de Cache

O cache é uma das maneiras mais eficazes de melhorar o desempenho e reduzir a carga em seus servidores de backend. O Nginx pode servir como um poderoso cache de conteúdo.

proxy_cache_path

Define o caminho para o diretório de cache, seu tamanho, o número de níveis de subdiretório e por quanto tempo os itens inativos permanecem no cache.

proxy_cache

Ativa o cache para um determinado bloco location, referenciando a zona definida em proxy_cache_path.

proxy_cache_valid

Define o tempo durante o qual o Nginx deve armazenar em cache respostas com códigos de status HTTP específicos.

proxy_cache_revalidate

Quando ativado, o Nginx usará cabeçalhos If-Modified-Since e If-None-Match para revalidar o conteúdo em cache com o backend, reduzindo o uso de largura de banda.

proxy_cache_use_stale

Instrui o Nginx a servir conteúdo em cache desatualizado se o servidor de backend estiver inativo, sem resposta ou com erros. Isso melhora muito a disponibilidade.

expires

Define os cabeçalhos Cache-Control e Expires para cache do lado do cliente de arquivos estáticos. Isso minimiza requisições repetidas ao Nginx.

http {
    # Define uma zona de cache de proxy no bloco http
    proxy_cache_path /var/cache/nginx/my_cache levels=1:2 keys_zone=my_cache:10m inactive=60m max_size=10g;

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://my_upstream_backend;
            proxy_cache my_cache; # Habilita o cache para esta localização
            proxy_cache_valid 200 302 10m; # Armazena em cache respostas bem-sucedidas por 10 minutos
            proxy_cache_valid 404 1m; # Armazena em cache 404s por 1 minuto
            proxy_cache_revalidate on;
            proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
            add_header X-Cache-Status $upstream_cache_status; # Ajuda na depuração
        }

        # Armazena em cache arquivos estáticos no navegador por um período mais longo
        location ~* \.(jpg|jpeg|gif|png|css|js|ico|woff|woff2|ttf|svg|eot)$ {
            expires 30d; # Cache por 30 dias
            add_header Cache-Control "public, no-transform";
            # Para arquivos estáticos, considere servir diretamente do Nginx se não estiverem sendo proxyados
            root /var/www/html;
        }
    }
}

5. Ative a Compressão Gzip

Comprimir as respostas antes de enviá-las aos clientes pode reduzir significativamente o uso de largura de banda e melhorar os tempos de carregamento da página, especialmente para conteúdo baseado em texto.

gzip on

Ativa a compressão gzip.

gzip_comp_level

Define o nível de compressão (1-9). O nível 1 é o mais rápido com menos compressão; o nível 9 é o mais lento com compressão máxima. O nível 6 geralmente oferece um bom equilíbrio.

gzip_types

Especifica os tipos MIME que devem ser comprimidos. Inclua tipos comuns de texto, CSS, JavaScript e JSON.

gzip_min_length

Define o comprimento mínimo de uma resposta (em bytes) para a qual a compressão deve ser ativada. Arquivos pequenos não se beneficiam muito e podem até ser mais lentos devido à sobrecarga de compressão.

gzip_proxied

Instrui o Nginx a comprimir respostas mesmo que sejam proxyadas. any é um valor comum.

gzip_vary

Adiciona o cabeçalho Vary: Accept-Encoding às respostas, informando aos proxies que a resposta pode diferir com base no cabeçalho da requisição Accept-Encoding.

http {
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6; # Nível de compressão 1-9 (6 é um bom equilíbrio)
    gzip_buffers 16 8k; # 16 buffers, cada um com 8KB
    gzip_http_version 1.1; # Versão mínima do HTTP para compressão
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;
    gzip_min_length 1000; # Comprime apenas respostas maiores que 1KB
}

6. Otimize o Registro em Log

Embora os logs sejam essenciais para monitoramento e solução de problemas, o registro excessivo ou não otimizado pode introduzir E/S de disco significativa, especialmente em sites de alto tráfego.

access_log

• Desative para ativos estáticos: Para conteúdo estático altamente acessado (imagens, CSS, JS), desabilitar access_log pode economizar muita E/S.
• Buffering: O Nginx pode armazenar em buffer entradas de log na memória antes de gravá-las em disco, reduzindo a frequência de gravações em disco. Os parâmetros buffer e flush são usados aqui.

error_log

Defina o nível de log apropriado (crit, error, warn, info, debug). Para produção, warn ou error geralmente é suficiente para capturar problemas críticos sem inundar os logs.

http {
    server {
        # Log de acesso padrão para conteúdo dinâmico
        access_log /var/log/nginx/access.log main;

        location ~* \.(jpg|jpeg|gif|png|css|js|ico|woff|woff2|ttf|svg|eot)$ {
            access_log off; # Desativa o registro para arquivos estáticos comuns
            expires 30d;
        }
    }

    # Exemplo de log de acesso com buffer para o contexto HTTP principal
    # access_log /var/log/nginx/access.log main buffer=16k flush=5s;
    error_log /var/log/nginx/error.log warn; # Registra apenas avisos e acima
}

7. Ajuste Timeouts

Timeouts configurados adequadamente impedem que o Nginx mantenha conexões inativas por muito tempo, liberando recursos.

Timeouts do Lado do Cliente

• client_body_timeout: Quanto tempo o Nginx espera que um cliente envie o corpo da requisição.
• client_header_timeout: Quanto tempo o Nginx espera que um cliente envie o cabeçalho da requisição.
• send_timeout: Quanto tempo o Nginx espera que um cliente aceite a resposta após ela ser enviada.

Timeouts de Proxy/FastCGI (se aplicável)

• proxy_connect_timeout: Timeout para estabelecer uma conexão com um servidor proxy.
• proxy_send_timeout: Timeout para transmitir uma requisição ao servidor proxy.
• proxy_read_timeout: Timeout para ler uma resposta do servidor proxy.

http {
    client_body_timeout 15s; # Cliente tem 15 segundos para enviar o corpo
    client_header_timeout 15s; # Cliente tem 15 segundos para enviar cabeçalhos
    send_timeout 15s; # Nginx tem 15 segundos para enviar resposta ao cliente

    # Para cenários de proxy
    proxy_connect_timeout 5s; # 5 segundos para conectar ao upstream
    proxy_send_timeout 15s; # 15 segundos para enviar requisição ao upstream
    proxy_read_timeout 15s; # 15 segundos para ler resposta do upstream

    # Para cenários FastCGI
    fastcgi_connect_timeout 5s;
    fastcgi_send_timeout 15s;
    fastcgi_read_timeout 15s;
}

8. Otimização SSL/TLS

Para sites habilitados para HTTPS, otimizar as configurações de SSL/TLS é crucial para reduzir a sobrecarga da CPU e melhorar o desempenho do handshake.

ssl_session_cache e ssl_session_timeout

Ative o cache de sessão SSL para evitar o handshake TLS completo, computacionalmente caro, para conexões subsequentes do mesmo cliente.

ssl_protocols e ssl_ciphers

Use protocolos TLS modernos como TLSv1.2 e TLSv1.3. Tenha cuidado com strings de cifra copiadas: as cifras TLS 1.3 não são controladas da mesma forma que os conjuntos de cifras TLS mais antigos, e os padrões de distribuição são geralmente mais seguros do que exemplos desatualizados de guias antigos.

ssl_stapling

Ativa o OCSP stapling, onde o Nginx busca periodicamente a resposta OCSP da CA e a "grampeia" ao handshake SSL/TLS. Isso reduz a latência do lado do cliente, evitando uma consulta OCSP separada.

server {
    listen 443 ssl;
    ssl_certificate /etc/nginx/ssl/your_domain.crt;
    ssl_certificate_key /etc/nginx/ssl/your_domain.key;

    ssl_session_cache shared:SSL:10m; # Cache compartilhado para 10MB de dados de sessão
    ssl_session_timeout 10m; # Sessões expiram após 10 minutos

    ssl_protocols TLSv1.2 TLSv1.3; # Use protocolos modernos e seguros
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
    ssl_prefer_server_ciphers on;

    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s; # Use resolvedores aprovados para seu ambiente
    resolver_timeout 5s;
}

9. Cache de Arquivos Abertos

O Nginx pode armazenar em cache descritores de arquivo para arquivos acessados com frequência, reduzindo a necessidade de chamadas de sistema repetidas para abrir e fechar arquivos.

open_file_cache

Ativa o cache, especificando o número máximo de elementos e por quanto tempo os elementos inativos permanecem.

open_file_cache_valid

Define com que frequência o cache deve verificar a validade de seus elementos.

open_file_cache_min_uses

Especifica o número mínimo de vezes que um arquivo deve ser acessado dentro do tempo inactive para permanecer no cache.

open_file_cache_errors

Determina se o Nginx deve armazenar em cache erros ao abrir arquivos.

http {
    open_file_cache max=100000 inactive=60s; # Armazena em cache até 100.000 descritores de arquivo por 60s
    open_file_cache_valid 80s; # Verifica a validade a cada 80 segundos
    open_file_cache_min_uses 1; # Armazena em cache arquivos usados pelo menos uma vez
    open_file_cache_errors on; # Armazena em cache erros relacionados à abertura de arquivos
}

10. Valide com Sinais de Tráfego Reais

O último item da lista de verificação é a medição. Antes de uma alteração, capture uma pequena linha de base: latência da requisição, taxa de 5xx, conexões ativas, CPU, memória, E/S de disco, taxa de transferência de rede e tempo de resposta do upstream. Após a alteração, compare os mesmos números.

Para um proxy reverso, $request_time e $upstream_response_time são especialmente úteis. Se ambos subirem juntos, o backend provavelmente está lento. Se $request_time estiver alto enquanto o tempo upstream estiver baixo ou vazio, observe a velocidade de upload do cliente, o tempo de transferência da resposta, o buffering, a compressão ou a entrega de arquivos estáticos. Se nenhuma métrica explicar o problema, verifique o log de erros e o sistema operacional.

A sequência de ajuste mais segura é simples: teste a configuração com nginx -t, recarregue em vez de reiniciar quando possível, monitore os logs e reverta rapidamente se a latência ou os erros se moverem na direção errada. O Nginx pode lidar com muito tráfego, mas apenas quando seus limites, o kernel e a aplicação upstream concordam entre si.