Saltar para o conteúdo 
Buffering do NGINX determina a rapidez com que o teu proxy recebe respostas do upstream, as armazena em buffer e as envia aos clientes, de forma a poupar memória. Vou mostrar-te como reduzo a latência, libero as ligações ao backend antecipadamente e o Memória manter isso sob controlo.
Pontos centrais
Os seguintes aspetos fundamentais ajudam-me a equilibrar de forma adequada o desempenho e os requisitos de memória.
- Desacoplamento A comunicação entre o cliente e o backend reduz o tempo de ligação e aumenta a taxa de transferência.
- Tamanhos dos buffers Selecione «exatamente» para poupar memória RAM e evitar operações de E/S no disco.
- buffers ocupados limitar a memória ativa durante a transmissão.
- Exceções ao streaming utilizar de forma prática, sem buffering.
- Monitorização e os testes de carga garantem a fiabilidade de cada alteração.
Como funciona o armazenamento em buffer do proxy no NGINX
Eu utilizo o ativo Armazenamento em buffer, para que o NGINX recolha rapidamente as respostas do upstream e, em seguida, as envie autonomamente aos clientes. Esta dissociação reduz a Latência no back-end, porque a aplicação fica pronta mais rapidamente e encerra a sua ligação mais cedo. Enquanto os clientes carregam a uma velocidade variável, a camada de proxy regula o envio a partir da memória RAM. Se os dados não couberem na totalidade na RAM, o NGINX pode recorrer temporariamente a ficheiros, conseguindo assim transmitir a resposta de forma fiável. É precisamente este comportamento que estabiliza sistemas sob forte carga com muitos Ligações.
Quando o buffering ativo é a melhor opção
No caso de aplicações web clássicas, APIs com respostas de tamanho médio ou pilhas do WordPress, proporciona Armazenamento em buffer regularmente os melhores resultados. Liberto o backend mais cedo, enquanto o NGINX se encarrega da transferência restante para redes de clientes frequentemente heterogéneas. Desta forma, aumenta-se a eficácia Rendimento, especialmente quando há muitas solicitações a decorrer em simultâneo. Quem agrupa vários serviços atrás de um proxy inverso beneficia adicionalmente da distribuição controlada da carga. Para questões de arquitetura relacionadas com proxies, ajuda-me ter uma visão clara Arquitetura do proxy invertido, que separa claramente as funções e os limites.
Armazenamento vs. E/S: o orçamento adequado
Equilibro a RAM e os acessos ao disco rígido, porque os buffers demasiado pequenos causam E/S de disco provocar e os buffers demasiado grandes aumentam excessivamente a memória por ligação. São determinantes os tamanhos típicos das respostas, as solicitações paralelas e a real Velocidade do cliente. Idealmente, as respostas pequenas permanecem totalmente na RAM, o que permite ao NGINX transmiti-las sem tempo de espera para destinatários mais lentos. Os corpos de resposta muito grandes podem ser gravados no disco, mas, nesse caso, certifico-me de que utilizo unidades rápidas e defino limites para evitar um I/O excessivo. Este equilíbrio mantém a Tempos de resposta baixa e protege o sistema contra a pressão no acumulador.
Visão geral das diretivas e valores de referência
Defino especificamente os parâmetros principais para controlar a memória e o comportamento de transmissão. O primeiro buffer para os cabeçalhos de resposta é anexado a proxy_buffer_size; evita erros de cabeçalho excessivamente grandes e evita transferências desnecessárias para a memória externa. Distribuo os dados da resposta propriamente ditos através de proxy_buffers como pares de número por tamanho, para que os «bodies» permaneçam totalmente na RAM, na medida do possível. Com proxy_busy_buffers_size Limito a quantidade de buffers já marcados para envio, a fim de controlar o consumo de memória ativa. Para determinar os tamanhos típicos, baseio-me nas páginas de memória (4–32 KB) e nos perfis de resposta conhecidos das minhas aplicações.
| diretiva | Efeito | Valores típicos | Notas |
|---|---|---|---|
| proxy_buffering | Ligar/Desligar da armazenagem temporária | ativado (predefinição) | Manter ativado para aplicações web padrão; verificar no caso de transmissões em direto |
| proxy_buffer_size | Buffer de cabeçalho | 8k–16k | Se for demasiado pequeno, dá origem a um erro „upstream sent too big header“ |
| proxy_buffers | Amortecedor de carroçaria | 8 de 16k, 16 de 16k | Associar a parâmetros de resposta e paralelismo |
| proxy_busy_buffers_size | Limite do buffer de envio | 32k–128k | Rendimento suficiente, sem ocupar memória RAM |
| proxy_max_temp_file_size | Limite de disco | 0–1 g | 0 desativa os ficheiros temporários |
| proxy_temp_path | Caminho para ficheiros temporários | Caminho do SSD | Gravar num suporte de dados de alta velocidade |
Perfis orientados para a prática e exemplos de cálculos
Calculo, de forma aproximada, a necessidade de memória por ligação ativa como a soma de proxy_buffer_size mais (N × tamanho do buffer) de proxy_buffers. Com 8 buffers de 16 k mais um cabeçalho de 16 k, chegamos a cerca de 144 KB por pedido, desde que tudo permaneça na RAM. Com 5 000 pedidos simultâneos, calculo, portanto, cerca de 720 MB de ocupação exclusiva do buffer, acrescida da sobrecarga do Processos. À medida que o tráfego aumenta, a procura também aumenta – por isso, defino as margens de segurança de forma a que as respostas típicas se encaixem, sem transformar casos excecionais com corpos de tamanho excessivo em casos normais. Sempre que necessário, limito as exceções com Limites de espaço em disco, para compensar os picos de consumo de energia.
Quando desativo o buffering de forma deliberada
As APIs em tempo real, os eventos enviados pelo servidor ou o vídeo em direto requerem uma ligação direta Rendimento sem armazenamento em buffer adicional. Nesses casos, desativo o proxy_buffering e opto por uma abordagem eficiente Streaming. O proxy transmite então os dados imediatamente, o que evita picos de latência nos dados em tempo real, mas mantém a ligação ao backend aberta durante mais tempo. Para estes padrões, vale a pena dar uma vista de olhos a Fluxo de resposta, incluindo um ajuste adequado dos parâmetros de keepalive e timeout. É importante ter sempre em conta o maior consumo de recursos por ligação e definir limites em conformidade.
Definir os «Busy Buffers» de forma seletiva
Com proxy_busy_buffers_size controlo a quantidade de memória „pronta para envio“ que permanece bloqueada em simultâneo. Se o limite for demasiado baixo, a entrega fica paralisada; se for demasiado alto, os picos de RAM aumentam. Por isso, escolho um valor que corresponda a 1 a 2 vezes o tamanho do buffer, para que o NGINX envie os pacotes rapidamente, sem sobrecarregar demasiado Memória para vincular. No caso de clientes lentos, aceito um pouco mais de espaço ocupado (busy-space) para reduzir o risco de mudanças de contexto frequentes. As redes rápidas beneficiam de valores mais reduzidos, que Requisitos de memória manter a previsibilidade.
Ficheiros temporários: caminho, tamanho, limites
Ativo temporariamente Arquivos apenas quando os «bodies» são grandes ou quando a memória RAM é escassa. Se os ficheiros temporários estiverem num SSD, os tempos de resposta mantêm-se aceitáveis; num disco mais lento, as operações de E/S acabam rapidamente por abrandar todo o Cadeia de respostas. Com o `proxy_max_temp_file_size`, protejo-me contra uma utilização excessiva de espaço; em caso de dúvida, defino um limite rígido. Se houver muitas respostas grandes em paralelo, prevejo espaço suficiente e monitorizo a utilização real. Quando há RAM disponível, prefiro buffers maiores e mantenho as partes críticas no Memória.
Ajuste iterativo, métricas e testes
Começo por ser conservador Valores, avalie, ajuste e repita o ciclo. As métricas importantes são a latência, a taxa de erros, os picos de RAM, os tempos de espera de E/S e a utilização da Trabalhador. Os testes de carga revelam efeitos que passam despercebidos no dia-a-dia, como picos no cabeçalho causados por cookies ou mega-respostas esporádicas. Além disso, ajusto os parâmetros de ligação e dos workers de forma integrada, por exemplo, Worker‑Connections e Keepalive. Verifico cada alteração de forma controlada, para poder avaliar o impacto da Tampão possa atribuir claramente.
Buffering de pedidos e uploads
Os buffers de resposta são apenas metade da verdade. No lado da entrada, controla-se proxy_request_buffering, se o NGINX armazena temporariamente os corpos das solicitações dos clientes (por exemplo, uploads) até estarem completos ou se os transmite imediatamente para o servidor upstream. No caso de APIs que recebem ficheiros de grande dimensão, costumo desativar o buffer de pedidos: o servidor upstream recebe o fluxo mais cedo, os tempos de espera diminuem e o NGINX não precisa de armazenar temporariamente corpos de grande dimensão no disco. A desvantagem: a ligação ao servidor upstream permanece aberta por mais tempo e depende mais da velocidade do cliente. No caso de formulários clássicos ou de pedidos JSON mais pequenos, o buffer de pedidos permanece ativado, para suavizar picos de tráfego de forma eficaz e controlar melhor os recursos do servidor. Combino isto com tamanho_max_do_corpo_do_cliente e uma adequada client_body_buffer_size, para que os valores atípicos sejam rejeitados atempadamente ou devidamente amortecidos.
Controlar o Pro-Response: X-Accel-Buffering, Chunked e comprimentos
Para um ajuste mais preciso, desativo o buffer por resposta através de X-Accel-Buffering Do upstream: o cabeçalho „X-Accel-Buffering: no“ indica ao NGINX para transmitir a resposta diretamente, mesmo que o proxy_buffering esteja ativado globalmente. Utilizo isto para SSE, long polling ou fluxos de diagnóstico, sem comprometer o ajuste geral. Além disso, certifico-me de que Comprimento do conteúdo, sempre que possível: se o NGINX conhecer o comprimento, planeia os buffers e os ficheiros temporários de forma mais previsível do que se, exclusivamente, em pedaços é transmitido. Quando o comprimento é desconhecido (por exemplo, transmissões em direto), faço uma estimativa conservadora das necessidades e defino limites de E/S. No caso de páginas de erro ou respostas JSON pequenas, mantenho o buffer desativado, para que a ligação a montante fique livre rapidamente.
Compressão e protocolos: HTTP/2/3 em destaque
A compressão e o armazenamento em buffer devem ser considerados em conjunto. É gzip ou com o Brotli ativo, a compressão beneficia da aglomeração de blocos de dados contíguos na RAM. Buffers demasiado pequenos podem limitar o débito, porque o compressor tem de mudar de contexto com maior frequência. Por isso, escolho tamanhos de buffer que agrupem bem os segmentos de resposta típicos, sem deixar que a RAM fique sobrecarregada por cada ligação. Em HTTP/2 e HTTP/3 Com multiplexação e controlo de fluxo, a velocidade de envio varia consoante o fluxo; o buffer estabiliza o lado do backend, enquanto o NGINX sincroniza os fluxos de forma precisa. Importante: em percursos muito sensíveis à latência, um „tick“ a menos de «Busy Space» pode ajudar a atenuar os efeitos «Head-of-Line»; em ligações «robustas» com janelas amplas, libero um pouco mais de «Busy Space» para manter o desempenho máximo de envio.
Cache do proxy e pedidos de intervalo: interação com os buffers
Quem proxy_cache , o orçamento para buffers e ficheiros temporários deve ser coordenado. O NGINX pode armazenar respostas em cache e entregá-las aos clientes simultaneamente; buffers de RAM suficientes reduzem o tempo de duração da ligação ao backend, enquanto o acerto no cache desconexiona totalmente as solicitações posteriores. Limito os ficheiros temporários de forma mais rigorosa quando a cache está «aquecida» e permito a sua criação enquanto a taxa de acertos está a aumentar. No caso de Pedidos de gama (Transferências parciais) decido se as sirvo diretamente a partir da cache ou se deixo que sejam primeiro armazenadas na totalidade na memória tampão. Intervalos frequentes de ficheiros de grande dimensão beneficiam de tamanhos de memória tampão cuidadosamente equilibrados e de respostas segmentadas (opcionalmente), para que nem a E/S do disco nem a RAM fiquem sobrecarregadas.
Clientes lentos: controlar a taxa de transferência sem esgotar a memória RAM
Grande parte dos efeitos de buffer só se torna visível com clientes muito lentos. Eu defino tempo_limite_de_envio e opcionalmente limit_rate/limit_rate_after, para proteger os destinatários hesitantes sem sobrecarregar os workers. Se houver uma forte limitação de largura de banda, os buffers «Busy» têm de aumentar, caso contrário há risco de bloqueios; ao mesmo tempo, controlo o número de ligações paralelas por IP para mitigar padrões anormais. Para downloads com uma base de utilizadores mista (telemóvel, Wi-Fi, fibra ótica), valores moderados de «Busy» e buffers «Body» um pouco mais generosos ajudam, de modo que o NGINX continue a enviar dados de forma linear enquanto o upstream já está ocupado com o pedido seguinte.
Operações em contentores e orquestração
Pretendo planear isso em contentores proxy_temp_path De forma consciente: ou um volume de host rápido (SSD) ou um tmpfs, se houver RAM suficiente. Os limites dos contentores (memória/CPU/armazenamento efémero) afetam diretamente as memórias tampão e os ficheiros temporários; mantenho margem suficiente para picos de carga e regulo o número de trabalhadores paralelos e de ligações em conformidade. É importante ter em conta ulimit -n (descritores de ficheiros) e as quotas do Orchestrator: se a memória efémera for demasiado pequena, os ficheiros temporários geram erros; se a RAM for insuficiente, os workers deixam de funcionar devido à pressão OOM. Dimensiono os buffers de forma a que os picos de carga típicos se mantenham estáveis dentro dos limites do contentor e monitorizo continuamente o espaço efetivamente ocupado pelos diretórios temporários.
Valores iniciais e modelo para aplicações web comuns
Como ponto de partida fiável, utilizo um perfil sucinto, que posteriormente aperfeiçoo com valores de medição. Exemplo:
location / {
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_buffering on;
# Buffer de cabeçalhos e corpo
proxy_buffer_size 16k;
proxy_buffers 16 16k;
proxy_busy_buffers_size 64k;
# Ficheiros temporários apenas como recurso de emergência
proxy_max_temp_file_size 256m;
proxy_temp_path /var/cache/nginx/proxy_temp 1 2;
# Tempos de espera e envio
proxy_read_timeout 60s;
send_timeout 30s;
# Opcional: streaming de upload consoante a API
# proxy_request_buffering off;
}
Desta forma, as respostas de tamanho médio permanecem na totalidade na RAM, o upstream fica livre rapidamente e os ficheiros temporários só são utilizados em casos de picos de tráfego. Na segunda fase, ajusto o número de buffers ao paralelismo efetivo, aumentei ligeiramente o tamanho do «busy» em caso de respostas curtas e frequentes, se necessário, e limitei mais rigorosamente os ficheiros temporários assim que a taxa de acertos na cache começou a dar resultados.
Monitorização e registo: tornar o impacto visível
Mido de forma consistente: $request_time e $upstream_response_time no registo de acesso, verificar se a ligação a montante é desligada prematuramente. $bytes_enviados e $body_bytes_sent ajudam a ajustar os perfis de buffer ao tráfego real. Se a diferença entre o tempo de upstream e a duração total diminuir, os buffers funcionam corretamente. Estabeleço uma correlação entre isto e os picos de RAM, a espera de E/S e a ocupação do proxy_temp_path. Nos testes de stress, varío as velocidades dos clientes, os tamanhos das respostas e a carga dos cabeçalhos (por exemplo, cookies), para identificar casos extremos. Só quando as métricas de registo e os valores do sistema se mantêm estáveis dentro do meu intervalo-alvo é que congelo o perfil e documento os limites, bem como os percursos de escalonamento (buffers maiores, outra política de tempo de espera, réplicas adicionais).
Erros frequentes e respetivas soluções
A mensagem „O cabeçalho enviado a montante é demasiado grande“Resolvo o problema aumentando o valor de `proxy_buffer_size` e, se necessário, aumentando o tamanho dos `proxy_buffers`. Se ocorrerem tempos de espera em dispositivos finais lentos, aumentei moderadamente os tempos de espera de envio e deixo um pouco de margem nos buffers ocupados. Se o diretório temporário ficar cheio, reduzo o tamanho máximo ou aumente os buffers de RAM, dependendo da relação custo-benefício. Se a entrega apresentar atrasos, verifico se há estrangulamentos de E/S, saturação da CPU e a distribuição dos Tampão. Quando se trata de situações de escassez, abordo-as sempre em primeiro lugar com base em valores medidos, e não com aumentos generalizados do dobro.
Conclusão: Os meus pontos-chave para o armazenamento em buffer do proxy NGINX
Começo por definir os típicos Tamanhos das respostas, picos de carga e perfis de cliente, antes mesmo de ajustar os buffers. Depois, defino um buffer de cabeçalho suficientemente grande para evitar erros desnecessários. Dimensiono os buffers de corpo de forma a que as respostas habituais permaneçam na RAM e apenas as exceções sejam Disco caem. Configuro os «Busy Buffers» de forma a que as transferências decorram de maneira fluida, sem desperdiçar memória. Por fim, verifico tudo através de testes de carga e monitorização, até que a latência, o débito e os requisitos de memória se situem num nível fiável Janelas mentira.
