O servidor Nginx dedicado usado para css / js / images é totalmente legal, mas as imagens carregam lentamente. Por quê?

Question

Temos três servidores dedicados em nossa empresa, um gerencia Nginx e atua como servidor web (php), outro gerencia MySQL e Memcached e o outro é usado para servir arquivos estáticos: css, js e imagens.

Todos os servidores aparecem com ótimo desempenho no New Relic, especialmente no servidor de arquivos estáticos:

• CPU continuamente abaixo de 10%
• Rede IO Recebido muito baixo, transmitido é em torno de 10 Mb / s no máximo, mas o servidor MySQL tem as mesmas especificações e rotineiramente alcança 20 mb / s, então duvide que isso seja um problema.
• Carga média abaixo de 0,5

O problema é que, nos horários de pico, aparentemente as imagens (que podem ter 100kb - 200kb de tamanho) levam muito tempo para serem carregadas por alguns usuários (muitos segundos, até um minuto às vezes, quando normalmente seriam necessários) apenas alguns segundos na pior das hipóteses).

Alguma ideia do que poderíamos fazer? Idealmente, se nem a CPU, a RAM ou a largura de banda atingissem qualquer tipo de limite, isso não deveria acontecer.

Quaisquer parâmetros chave de configuração do Nginx que deveríamos estar olhando (e provavelmente mudando)?

    

Answer 1

Existem duas possibilidades em que posso pensar.

1. Seu disco atingiu o limite de E / S.
2. Você atingiu o limite do segmento de trabalho em nginx. Veja os parâmetros de configuração worker_ * do módulo principal e worker_connections do módulo Eventos para descobrir como aumentar isso. O padrão é um único processo de trabalho, que é de encadeamento único, portanto, se você estiver executando em uma plataforma multi-cpu, deverá impulsionar isso. Mesmo se você estiver em uma única unidade de CPU, você se beneficiará com o aumento desse número em uma máquina que atende recursos estáticos, já que estará com E / S de disco muito antes de qualquer outra coisa, e outras threads podem receber e processar mais solicitações o primeiro está sentado esperando para receber dados do disco.

Answer 2

Poderíamos sentar aqui e adivinhar onde está o seu gargalo o dia todo, mas alguns conselhos mais gerais ajudarão você a encontrá-lo por conta própria mais cedo.

jeffatrackaid escreveu esta resposta ontem que é mais uma versão sucinta de que eu escrevi bastante enquanto atrás . Eu sugeriria ler os primeiros para ajudar a entender como a depuração de desempenho é feita.

No seu caso, eu usaria o Firebug primeiro para determinar qual bit da solicitação durante os horários de pico está indo devagar. Isso deve excluir a largura de banda se a largura de banda não for o verdadeiro problema. Procure na seção "Net" do Firebug e observe qual parte da solicitação muda entre os tempos rápidos e lentos.

Depois disso, eu executaria um strace com as opções -t e -T em um dos trabalhadores nginx durante um desses tempos lentos. A análise da saída disso deve mostrar exatamente onde o nginx está indo devagar. É útil gravar a saída strace em um arquivo e, em seguida, usar less ou grep no arquivo para identificar as chamadas do sistema que levaram muito tempo.

Você pode obter algum uso da opção -c para rastrear.

Depois de identificar as chamadas de sistema lentas, ainda pode haver algum trabalho para descobrir qual parâmetro nginx precisa mudar, mas você deve estar bem no caminho. Por favor, volte e faça perguntas mais específicas se precisar de ajuda com essa parte.

Se for uma chamada de sistema baseada em arquivo, não deixe de olhar para trás no rastreio até encontrar o arquivo que estava aguardando. Isso será uma grande dica.