Fluxo de processamento HTTP do Nginx: Ajuste da configuração

A configuração padrão do Nginx foi concebida para compatibilidade, não para desempenho. Com um ajuste adequado, um único servidor pode processar 50 000 a 80 000 pedidos por segundo. Este guia aborda as definições mais importantes: processos de trabalho, ligações, keepalive, armazenamento em buffer, equilíbrio de carga e como verificar as suas alterações com testes de desempenho.

Como o Nginx processa pedidos HTTP

O Nginx trata as solicitações em fases distintas, cada uma consumindo recursos do sistema. Compreender o fluxo ajuda a definir as configurações corretas.

Começa ao nível do kernel. As ligações recebidas chegam às filas SYN e ACCEPT, e os processos de trabalho do Nginx recolhem-nas. Uma vez aceites, o processo de trabalho analisa a solicitação HTTP a partir do buffer do kernel. O tráfego TLS torna esta etapa mais exigente em termos de CPU.

Em seguida, o Nginx associa a solicitação a um servidor virtual usando o cabeçalho Host e a combinação de IP/porta, e depois resolve a URI para um bloco de localização por meio de correspondência de prefixo ou expressão regular.

Para conteúdo dinâmico, o Nginx encaminha a solicitação para um backend (FastCGI, proxy). Esta fase de comunicação upstream beneficia-se fortemente de conexões persistentes. Sem o keepalive upstream, o Nginx abre uma nova conexão TCP por solicitação, aumentando a latência e a sobrecarga da CPU.

Se proxy_buffering estiver ativado, o Nginx lê a resposta upstream completa na memória antes de a entregar ao cliente. Isto liberta o worker para tratar novas solicitações imediatamente. Por fim, durante a entrega da saída, ativar sendfile permite transferências sem cópia, o que pode aumentar a taxa de transferência de cerca de 6 Gbps para 30 Gbps.

Cada fase consome buffers de memória, descritores de ficheiros e ciclos de CPU. As secções abaixo abordam cada um desses pontos de estrangulamento.

Processos de trabalho e ligações

Comece com worker_processes auto; no seu contexto principal. Isto faz corresponder o número de trabalhadores aos núcleos do seu CPU. Num VPS com núcleos limitados, defina o número manualmente (por exemplo, worker_processes 2;). Se a sua carga de trabalho for intensiva em memória, considere reduzir o número de trabalhadores para evitar sobrecarregar a RAM.

Ative worker_cpu_affinity auto; para fixar cada trabalhador a um núcleo específico. Isto reduz as falhas de cache e a alternância de contexto. Disponível desde o Nginx 1.9.10.

Limites de conexão

A worker_connections diretiva define quantas ligações simultâneas cada worker pode gerir. A capacidade total é worker_processes × worker_connections. O valor padrão de 512 ou 1.024 é demasiado baixo para produção. Defina-o para 2.048 ou 4.096 por worker para sites de tráfego intenso.

Cada ligação necessita de, pelo menos, um descritor de ficheiro. Numa configuração de proxy reverso, cada ligação utiliza dois (um para o cliente, outro para o upstream). Defina worker_rlimit_nofile para pelo menos o dobro do seu worker_connections valor com margem de segurança. Para worker_connections 4096;, utilize worker_rlimit_nofile 10000; ou superior.

Ao nível do sistema, aumente fs.file-max em /etc/sysctl.conf para pelo menos 500 000 e defina o LimitNOFILE=65535.

Por fim, adicione multi_accept on; no bloco de eventos para que os workers aceitem todas as ligações pendentes de uma só vez, em vez de uma de cada vez.

Timeouts e Keepalive

Keepalive do cliente

A keepalive_timeout diretiva controla por quanto tempo as ligações inativas do cliente permanecem abertas. Para servidores de tráfego intenso, 30 a 65 segundos funciona bem. Utilize a forma de dois parâmetros:

keepalive_timeout 65s 60s;

O primeiro valor é o tempo limite do lado do servidor. O segundo envia um Keep-Alive: timeout=60 cabeçalho para o cliente. Definir o valor do cliente ligeiramente mais baixo evita condições de corrida em que os navegadores tentam reutilizar ligações que o Nginx já fechou.

A keepalive_requests diretiva limita o número de pedidos que uma única ligação processa antes de ser encerrada. O valor predefinido é 1.000 (aumentado de 100 na versão 1.19.10). Para backends estáveis, aumente este valor para 10.000 para reduzir a rotatividade de ligações.

Os tempos de espera do proxy

proxy_connect_timeout define quanto tempo o Nginx espera para estabelecer uma ligação com o backend. O valor predefinido é 60 segundos. Reduza-o para 5 a 10 segundos para uma failover rápida.

proxy_read_timeout define quanto tempo o Nginx espera entre leituras sucessivas do upstream. Alinhe-o com o tempo limite de execução do seu backend. Se o do PHP-FPM request_terminate_timeout for de 120 segundos, defina proxy_read_timeout para pelo menos 120 segundos para evitar erros 504 prematuros.

proxy_send_timeout controla o intervalo entre gravações sucessivas no upstream. O valor padrão de 60 segundos geralmente é adequado, a menos que esteja a enviar corpos de pedidos grandes.

Como regra geral, proxy_connect_timeout deve ser sempre o mais curto dos três.

Dimensionamento do buffer

client_body_buffer_size controla a quantidade do corpo de uma solicitação recebida que o Nginx mantém na memória. O valor padrão de 8k ou 16k lida com envios de formulários simples, mas os uploads de ficheiros serão transferidos para o disco. Aumente-o para 128k para uploads de pequeno a médio porte. Aumente client_max_body_size o valor padrão de 1 MB se os utilizadores carregarem ficheiros maiores.

proxy_buffer_size lida com os cabeçalhos de resposta separadamente do corpo. O valor padrão de 4k ou 8k geralmente funciona, mas aplicações com grandes Set-Cookie (comuns no comércio eletrónico) podem excedê-lo, causando erros 502. Meça o tamanho real dos seus cabeçalhos:

curl -s -w '%{size_header}' -o /dev/null http://your-upstream-url

Arredonde para o incremento de 4k mais próximo.

proxy_buffers define o número e o tamanho dos buffers para o corpo da resposta. O valor padrão (8 buffers de 4k ou 8k, totalizando 32k a 64k) não suportará uma resposta JSON grande. Meça a sua maior resposta típica com curl e configure buffers suficientes para a manter inteiramente na RAM.

Comportamento do buffer do proxy

Com proxy_buffering on (o padrão), o Nginx lê a resposta completa do servidor upstream na memória antes de a enviar para o cliente. Isto permite que os servidores backend passem imediatamente para novos pedidos.

Defina proxy_busy_buffers_size para pelo menos proxy_buffer_size mais um buffer, mas menos do que o seu conjunto total de buffers. Para proxy_buffers 8 16k (128k no total), mantenha proxy_busy_buffers_size abaixo de 112k.

Para pontos finais em tempo real, como Server-Sent Events ou long-polling, desative o buffer com proxy_buffering off num bloco específico do local. Aplique isto seletivamente a /stream ou /events caminhos, não globalmente.

Equilíbrio de carga e Keepalive upstream

Por predefinição, o Nginx abre uma nova ligação TCP para cada pedido proxy. Cada handshake adiciona 10 a 100 ms de latência, com o TLS a adicionar mais 10 a 50 ms. O keepalive upstream mantém um conjunto de ligações persistentes para eliminar esta sobrecarga.

São necessárias três configurações:

upstream backend {
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    keepalive 128;
}
 
server {
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

O keepalive valor define o número máximo de ligações inativas por worker. Calcule o tamanho ideal do conjunto da seguinte forma: (workers × target concurrency) / upstream nodes.

Defina o upstream keepalive_timeout para 60 a 120 segundos para corresponder às configurações do seu backend e lidar com picos de tráfego.

Estratégias de balanceamento

O Nginx suporta vários métodos de balanceamento de carga. O round-robin (padrão) distribui as solicitações sequencialmente. least_conn O round-robin direciona para o servidor com o menor número de ligações ativas, o que é adequado para cargas de trabalho com durações de pedidos variáveis. ip_hash proporciona persistência de sessão ao encaminhar o mesmo IP do cliente para o mesmo backend.

Utilize o weight parâmetro quando os servidores têm capacidades diferentes:

upstream backend {
    least_conn;
    server 10.0.1.10:8080 weight=3;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080 backup;
    keepalive 128;
}

O servidor ponderado recebe o triplo do tráfego. O backup servidor só é ativado se todos os servidores primários estiverem inativos. Configure max_fails e fail_timeout para verificações de integridade passivas e utilize max_conns para limitar as ligações simultâneas por backend.

Testes e monitorização

Meça sempre o desempenho de referência antes de alterar qualquer coisa. Após cada alteração, faça novamente o benchmark. Faça uma alteração de cada vez.

Valide a sintaxe da sua configuração com nginx -t antes de recarregar. Execute os testes de desempenho a partir de uma máquina separada para evitar conflitos de recursos.

O wrk é a ferramenta padrão para testes de carga HTTP:

wrk -t4 -c200 -d30s http://your-server.com/

Acompanhe as solicitações por segundo, a latência média, a latência máxima e a taxa de transferência. O Apache Bench funciona para testes mais simples:

ab -n 50000 -c 40 http://your-server.com/

Monitorização contínua

Ative o stub_status módulo para monitorizar ligações ativas em tempo real através de curl http://localhost/nginx_status.

Adicione variáveis de tempo ao seu formato de registo para identificar onde ocorrem atrasos:

• $request_time para a duração total da solicitação
• $upstream_connect_time para o tempo de ligação ao backend
• $upstream_response_time para o tempo total de processamento do backend

Verifique os registos de erros para problemas de buffer com journalctl -u nginx --no-pager | grep "temporary file". Se as respostas estiverem a atingir o disco, o seu proxy_buffers são demasiado pequenos. Procure erros do tipo «demasiados ficheiros abertos», que indicam worker_rlimit_nofile que é necessário aumentar.

Reduza a E/S de registo com registo em buffer:

access_log /var/log/nginx/access.log combined buffer=64k flush=5s;

Utilize ss -tn state established dst [backend_ip] durante testes de carga para verificar se as ligações estão a ser reutilizadas e não se acumulam em TIME_WAIT.

Para servidores dedicados e alojamento VPS otimizados para cargas de trabalho de alto desempenho, consulte os Servidores FDC.