uma resposta upstream é armazenada em buffer em um arquivo temporário

uma resposta upstream é armazenada em buffer em um arquivo temporário

Eu tenho um aplicativo da web bastante grande e lento (dados complexos, front-end complexo) integrado RoRe servido Pumacomo nginxproxy reverso. Olhando para o nginxlog de erros, vejo algumas entradas como:

2014/04/08 09:46:08 [warn] 20058#0: *819237 an upstream response is buffered to a temporary file 
    /var/lib/nginx/proxy/8/47/0000038478 while reading upstream, 
    client: 5.144.169.242, server: engagement-console.foo.it, 
    request: "GET /elements/pending?customer_id=2&page=2 HTTP/1.0", 
    upstream: "http://unix:///home/deployer/apps/conversationflow/shared/sockets/puma.sock:/elements/pending?customer_id=2&page=2", 
    host: "ec.reputationmonitor.it", 
    referrer: "http://ec.foo.it/elements/pending?customer_id=2&page=3"

Estou bastante curioso, pois é muito improvável que a página permaneça a mesma para diferentes usuários e diferentes interações do usuário, e não acho que armazenar em buffer a resposta no disco seja necessário/útil.

Eu sei proxy_max_temp_file_sizee defini-lo como 0, mas me parece um pouco estranho (meu proxy tenta armazenar em buffer, mas não tem nenhum arquivo para armazenar em buffer ... como isso pode ser mais rápido?).

Minhas perguntas são:

  1. Como posso remover o [aviso] e evitar o buffer de respostas? É melhor desligar proxy_bufferingou definir proxy_max_temp_file_sizecomo 0? Por que?

  2. Se nginxarmazena uma resposta em buffer: quando ela serve a resposta em buffer, para quem e por quê?

  3. Por que nginxé proxy_bufferingativado por padrão e depois [avisa] se ele realmente armazena uma resposta em buffer?

  4. Quando uma resposta aciona essa opção? Quando leva > alguns segundos (quantos?) para fornecer a resposta? Isso é configurável?

TIA, claro.

Responder1

  1. Como posso remover o [aviso] e evitar o buffer de respostas? É melhor desligar o proxy_buffering ou definir proxy_max_temp_file_size como 0? Por que?

Você deve definir proxy_max_temp_file_sizecomo 0 para removê-lo. A proxy_bufferingdiretiva não está diretamente relacionada ao aviso. Você pode desligá-lo para interromper qualquer buffer, mas isso não é recomendado em geral (a menos que seja necessário paraCometa).

  1. Se o nginx armazena uma resposta em buffer, quando ele atende a resposta em buffer, para quem e por quê?

Ele fornece a resposta imediatamente, mas um cliente geralmente tem uma conexão muito mais lenta e não consegue consumir os dados de resposta tão rapidamente quanto são produzidos pelo seu aplicativo. O Nginx tenta armazenar toda a resposta em buffer para liberar seu aplicativo o mais rápido possível.

Veja também:http://aosabook.org/en/nginx.html

  1. Por que o nginx ativa o proxy_buffering por padrão e depois [avisa] se ele realmente armazena uma resposta em buffer?

Como já mencionei, o proxy_bufferingnão está diretamente relacionado ao aviso. Geralmente é necessário para operações de proxy otimizadas e desligá-lo degrada o desempenho e o rendimento.

O Nginx avisa apenas quando uma resposta não cabe nos buffers de memória configurados. Você pode ignorar o aviso se estiver tudo bem para você.

  1. Quando uma resposta aciona essa opção? Quando leva mais de alguns segundos (quantos?) para fornecer a resposta? Isso é configurável?

Ele é acionado quando os buffers de memória estão cheios. Por favor, veja a documentação, todo o mecanismo está explicado:http://nginx.org/r/proxy_max_temp_file_size

Você pode querer aumentar os buffers de memória.

Responder2

A configuração a seguir funciona bem no meu servidor.

proxy_buffers 16 16k;  
proxy_buffer_size 16k;

Responder3

O comando nginx sendfile pode ajudar com isso para conteúdo estático

https://docs.nginx.com/nginx/admin-guide/web-server/serving-static-content/

Habilitando sendfile:

Por padrão, o NGINX cuida da transmissão do arquivo e copia o arquivo no buffer antes de enviá-lo. A ativação da diretiva sendfile elimina a etapa de cópia dos dados no buffer e permite a cópia direta dos dados de um descritor de arquivo para outro. Para evitar que uma conexão rápida ocupe totalmente o processo de trabalho, você pode usar a diretiva sendfile_max_chunk para limitar a quantidade de dados transferidos em uma única chamada sendfile() (neste exemplo, para 1 MB):

location /mp3 {
    sendfile           on;
    sendfile_max_chunk 1m;
    #...
}

Responder4

Adicione-os ao contexto do arquivo de configuração nginx.conf ou do host virtual (http,servidor,localização):

proxy_max_temp_file_size 10240m;
proxy_buffers 240 240k;
proxy_busy_buffers_size 240k;
proxy_buffer_size 240k;

Você pode definir os valores de acordo com sua situação, mas eles devem ter equilíbrio entre si (não use números diferentes para diretivas de buffer).

Eu tenho o mesmo problema e testei essas configurações para um script com processo de IO, SQL e php pesado e demorado, e funciona bem.

informação relacionada