Temos três servidores dedicados em nossa empresa, um roda Nginx e atua como servidor web (php), outro lida com MySQL e Memcached e o outro é usado para servir arquivos estáticos: css, js e imagens.
Todos os servidores apresentam ótimo desempenho no New Relic, especialmente o servidor de arquivos estáticos:
- CPU continuamente abaixo de 10%
- Network IO Recebido muito baixo, transmitido em torno de 10 Mb/s no máximo, mas o servidor MySQL tem as mesmas especificações e picos rotineiros de 20 mb/s, então duvido que isso seja um problema.
- Média de carga abaixo de 0,5
O problema é que, em horários de pico, aparentemente as imagens (que podem ter de 100kb a 200kb de tamanho) demoram muito para carregar para alguns usuários (muitos segundos, às vezes até um minuto, quando normalmente levaria 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 atingiram qualquer tipo de limite, isso não deveria acontecer.
Algum parâmetro-chave de configuração do Nginx que deveríamos observar (e provavelmente alterar)?
Responder1
Existem duas possibilidades em que posso pensar.
- Seu disco atingiu o limite de E/S.
- Você atingiu o limite de threads de trabalho no nginx. Olhe para atrabalhador_*parâmetros de configuração do módulo Core econexões_de_trabalhadordo módulo Eventos para descobrir como impulsionar isso. O padrão é um processo de trabalho único, que é de thread único, portanto, se você estiver executando em uma plataforma com várias CPUs, definitivamente deverá aumentá-lo. Mesmo se você estiver em uma caixa de CPU única, você se beneficiará ao aumentar esse número em uma máquina que atende recursos estáticos, pois estará vinculado à E/S do disco muito antes de qualquer outra coisa, e outros threads podem receber e processar mais solicitações enquanto o primeiro está esperando para receber dados do disco.
Responder2
Poderíamos ficar sentados aqui e adivinhar onde está o seu gargalo o dia todo, mas alguns conselhos mais gerais ajudarão você a encontrá-lo sozinho muito mais cedo.
jeffatrackaid escreveuesta resposta ontemque é uma versão mais sucinta deo que escrevi há algum tempo. Sugiro lê-los primeiro para ajudar a entender como a depuração de desempenho é feita.
No seu caso, eu usaria o Firebug primeiro para determinar qual parte da solicitação durante os horários de pico está lenta. Isso deve excluir a largura de banda se a largura de banda não for o verdadeiro problema. Veja na seção "Net" do Firebug e veja qual parte da solicitação muda entre os tempos rápidos e os tempos lentos.
Depois disso, eu executaria um strace com as opções -te -Tem um dos trabalhadores do nginx durante um desses tempos de lentidão. A análise do resultado disso deve mostrar exatamente onde o nginx está ficando lento. É útil gravar a saída do strace em um arquivo e então usar lessou grepno arquivo para identificar chamadas do sistema que demoraram muito.
Você pode aproveitar a -copção de strace.
Depois de identificar as chamadas lentas do sistema, ainda pode ser trabalhoso descobrir qual parâmetro do nginx precisa ser alterado, mas você deve estar no caminho certo. Volte e faça perguntas mais específicas se precisar de ajuda com essa parte.
Se for uma chamada de sistema baseada em arquivo, certifique-se de olhar para trás no rastreamento até encontrar o arquivo que estava esperando. Essa será uma grande dica.