Por que o tempo de resposta está explodindo quando a freqüência de solicitação cai?

Question

Correção : o tempo de resposta ( %D ) é μs não ms! 1

Isso não muda nada sobre a estranheza desse padrão, mas significa que é praticamente menos devastador.

Por que o tempo de resposta está inversamente correlacionado à freqüência de solicitações?

O servidor não deve responder mais rápido quando estiver menos ocupado lidando com solicitações?

Alguma sugestão de como fazer com que o Apache "aproveite" menos carga?

Essepadrãoéperiódico.Issosignificaqueeleapareceráseasimpressõescaíremabaixodecercade200solicitaçõesporminuto-oqueacontece(devidoàatividadenaturaldousuário)detardedanoiteatéoiníciodamanhã.

Assolicitaçõessãomuitosimples.OsPOSTsenviamumJSONcommenosde1000caracteres-esseJSONéarmazenado(anexadoaumarquivodetexto)-éisso.Arespostaéapenas"-".

Os dados mostrados nos gráficos foram registrados com o próprio Apache:

LogFormat "%{%Y-%m-%d+%H:%M:%S}t %k %D %I %O" performance
CustomLog "/var/log/apache2/performance.log" performance

    

Answer 1

Esse é um comportamento comum em data centers. As vezes que seu tempo de resposta é lento corresponde ao que é comumente chamado de Janela de Lote. Esse é um período em que a atividade do usuário deve ser baixa e os processos em lote podem ser executados. Backups também são feitos durante este período. Essas atividades podem sobrecarregar os recursos do servidor e das redes, causando problemas de desempenho, como você vê.

Existem alguns recursos que podem causar problemas:

• Carga alta da CPU. Isso pode fazer com que o apache espere que uma fatia de tempo processe a solicitação.
• Alto uso de memória. Isso pode liberar buffers que permitem que o apache sirva recursos sem lê-los do disco. Também pode causar paginação / troca de funcionários do apache.
• Alta atividade de disco. Isso pode fazer com que a atividade de E / S do disco seja enfileirada com os atrasos correspondentes na exibição do conteúdo.
• Alta atividade de rede. Isso pode fazer com que os pacotes sejam enfileirados para transmissão, aumentem as tentativas e degradem o serviço.

Eu uso sar para investigar como esse. atsar pode ser usado para reunir sar dados em arquivos de dados diários. Eles podem ser examinados para ver como é o comportamento do sistema durante o dia, quando o desempenho é normal, e durante a noite, quando o desempenho é variável.

Se você estiver monitorando o sistema com munin ou algum outro sistema que reúna e represente graficamente a utilização de recursos, você poderá encontrar alguns indicadores. Ainda acho sar mais preciso.

Existem ferramentas como nice e ionice que podem ser aplicadas a processos em lote para minimizar o impacto. Eles são eficazes apenas para problemas de CPU ou E / S. É improvável que resolvam problemas com memória ou atividade de rede.

Mover a atividade de backup para uma rede separada e reduzir a contenção de rede. Algum software de backup pode ser configurado para limitar a largura de banda que será usada. Isso poderia resolver a contenção de rede.

Dependendo de como os processos em lote são acionados, você pode limitar o número de processos em lote em execução paralelamente. Isso pode, na verdade, melhorar o desempenho dos processos em lote, pois provavelmente eles estão enfrentando a mesma contenção de recursos.

    

Answer 2

Essa relação pode acontecer na outra direção se os remetentes da solicitação aguardarem a conclusão de uma solicitação anterior antes de enviar uma nova. Nesse caso, o tráfego diminui à medida que o tempo de solicitação aumenta (por qualquer motivo), devido ao enfileiramento do lado do cliente.

Ou pode ser um artefato da sua medição - se o gráfico acima mostrar solicitações concluídas , ao contrário de solicitações de chegada , a taxa diminuirá conforme o tempo de processamento da solicitação aumentar (assumindo capacidade finita: D).

    

Answer 3

Embora a resposta da @TayThor possa estar correta, parece improvável que o período de baixa carga seja inteiramente absorvido pelos processos de backup (isto é, que os períodos correspondam precisamente).

Uma explicação alternativa é simplesmente o armazenamento em cache. Se um determinado script / banco de dados / o que não foi usado recentemente, os dados relevantes em cache podem ter sido descartados para liberar memória para o restante do sistema operacional. Isso pode ser índices em um banco de dados, ou buffers O / S em relação a um arquivo, ou qualquer outra coisa semelhante. Uma consulta terá que reconstituir essa informação se já passou algum tempo desde a última consulta. Em períodos de maior movimento, isso não ocorrerá, pois a última consulta será freqüente. Isso também explica por que você está vendo tempos de resposta baixos e altos tempos de resposta durante o período ocupado.

    

Answer 4

O que você está vendo parece, para mim, como se fosse uma questão estatística. Pode não ser, a resposta do @BillThor pode estar certa, mas vou postar isso para completar.

Os gráficos de tempo de resposta são baseados em percentis. Um conjunto de amostras de 800-1000 solicitações é uma boa contagem de amostras para isso, um conjunto de 50 a 100 solicitações talvez não tanto.

Se você assumir que o número de solicitações lentas não é uma função linear do volume de solicitações, de modo que uma ordem de magnitude de aumento nas solicitações não resulte em um aumento de ordem de magnitude nas solicitações lentas, maiores volumes de solicitações resultará em menor tempo médio de solicitação.

    

Answer 5

Existem mentiras, grandes mentiras e estatísticas.

Minha hipótese: você tem três categorias distintas de solicitações:

1. O fluxo de variável normal que contém a maioria das solicitações e todas elas estão concluídas em 200-300 μs.
2. Fluxo pequeno a uma taxa constante de cerca de 20 solicitações por minuto (mesmo à noite). Cada um leva cerca de 2.500 μs para completar.
3. Fluxo minúsculo a uma taxa constante de cerca de 10 solicitações por minuto (mesmo à noite). Cada um leva bem acima de 4.000 μs.

À noite, os 50 pedidos por minuto são correspondentemente 20 + 20 + 10. E assim, o resultado do percentil de 50% agora depende muito do resultado do fluxo 2. E o percentil de 95% depende do fluxo 3, de modo que ele nunca pode aparecer no gráfico.

Durante o dia, os fluxos 2 + 3 estão bem escondidos acima do percentil de 95%.

    

Answer 6

Quanto mais eu olho para isso, mais estou inclinado a pensar que há um problema com a coleta de dados.

Primeiramente, há algo realmente estranho acontecendo com o seu TPS. Embora o padrão geral pareça normal, há uma quebra acentuada muito ocorrendo por volta das 9h, e novamente às 7h. Um gráfico normal será muito mais suave durante a transição para horários fora do horário de pico.

Isso sugere que há uma alteração no perfil e, possivelmente, você tem dois tipos distintos de clientes:

1. Um que opera somente entre as 7h e 9h, em grandes volumes e
2. outro que provavelmente opera o tempo todo, em volumes menores.

A segunda dica é por volta das 18:00. Na maior parte do tempo, antes e depois, temos o perfil de volume alto - alto TPS e baixa latência. Mas por volta das 18:00 há uma queda repentina de 800-1000 RPM para menos de 400 RPM. O que poderia causar isso?

A terceira dica é a redução nos tempos de resposta do 5º percentil. Eu realmente prefiro observar os tempos mínimos de resposta (mas o percentil 5 é possivelmente melhor) por duas razões: ele me diz tempo de serviço (ex. Tempo de resposta menos enfileiramento), e os tempos de resposta tendem a seguir um Distribuição Weibull, o que significa que o modo (ou o valor mais comum) está um pouco acima do mínimo.

Assim, o step-down no 5º percentil me diz que há uma quebra repentina na série, e o tempo de serviço caiu mesmo que tanto a variância quanto os tempos médios de resposta tenham aumentado muito.

Próximas etapas

Nesta fase, eu faria um mergulho profundo nos logs para descobrir o que há de diferente nas amostras de 18:00 de baixo volume em comparação com as amostras de alto volume antes e depois.

Eu procuraria:

• diferenças na localização geográfica (caso a latência esteja afetando o $ request_time)
• diferenças na URL (não deve ser nenhuma)
• diferenças no método HTTP (POST / GET) (deve ser nenhum)
• solicitações repetidas do mesmo IP
• e outras diferenças ...

BTW, o "evento" de 18:00 é evidência suficiente para mim de que não tem nada a ver com o congestionamento / atividade do data center. Para que isso seja verdade, o congestionamento teria que causar uma queda no TPS, o que é possível às 18:00, mas é extremamente improvável que esteja causando uma queda suave e sustentada no TPS por 10 horas entre 21h e 7h.