Análise dos resultados do teste de estresse

Todos os dias no mundo existem cada vez mais ferramentas para a realização de testes de resistência. Na verdade, o próprio interesse por esse assunto está começando a crescer.

A principal tarefa de uma ferramenta de teste de carga é aplicar uma determinada carga ao sistema. Mas, além disso, há mais uma tarefa não menos importante - fornecer um relatório sobre os resultados do envio dessa carga. Caso contrário, realizaremos testes, mas não poderemos dizer nada sobre seu resultado e não poderemos determinar com precisão a partir de que momento começou a degradação do sistema.



As ferramentas de teste mais populares no momento são Gatling, MF LoadRunner, Apache JMeter. Todos eles têm a capacidade de gerar relatórios prontos sobre os testes realizados, bem como gráficos individuais ou dados brutos, com base nos quais o próprio relatório é construído.







Antes de escrever qualquer relatório, você precisa entender para quem o estamos redigindo e que propósito buscamos. Não faz sentido adicionar muitos gráficos de tempo de resposta do aplicativo ao relatório para cada operação se seu objetivo é determinar se há vazamentos de memória, se a operação instável foi corrigida durante um teste de confiabilidade ou se você precisa comparar duas versões entre si como parte do teste de regressão. Para responder a essas perguntas, você só precisa de alguns gráficos, a menos, é claro, que tenha corrigido os problemas e não queira entendê-los. Portanto, antes de criar um relatório, pense se você realmente precisa adicionar todos os gráficos a ele ou apenas os mais indicativos e dar uma resposta ao propósito do teste. Além disso, o conjunto de gráficos e suas análises para o relatório dependem do modelo de carga selecionado - fechado ou aberto,já que modelos diferentes darão números diferentes nos gráficos.



Nós da Tinkoff usamos ativamente a ferramenta Gatling, portanto, a partir de seu exemplo, vamos lhe ensinar como criar um relato de seus sonhos e onde olhar ao analisá-lo. Também quero observar imediatamente que quase todos os gráficos descritos no artigo podem ser obtidos online usando um pacote de sua ferramenta com Grafana. É a ferramenta mais conveniente para criar relatórios dinâmicos usando um painel pré-configurado. Além disso, permite que você crie mais rapidamente quase qualquer gráfico com base nos dados que você envia. Já existem painéis prontos para quase todas as ferramentas de teste de carga. Gráficos para outras ferramentas - MF LoadRunner e Apache JMeter - também serão fornecidos, sua análise é construída por analogia com Gatling.

Métricas básicas

Indicadores

Mostra a distribuição quantitativa e percentual do tempo de resposta da solicitação por grupo. Os gráficos desse tipo são convenientes para fornecer uma avaliação preliminar rápida dos resultados do teste, sem uma análise mais profunda do restante dos gráficos.



Os limites de grupo a grupo são predefinidos com base na revisão por pares ou SLA (requisitos não funcionais). Por exemplo, pode haver três grupos:

• excelente - tempo de resposta inferior a 50 segundos;
• médio - mais de 50, mas menos de 100 segundos;
• terrível - mais de 100 segundos.

No Gatling, você mesmo pode configurar os limites para mover de grupo para grupo e seu número no arquivo gatling.conf. É melhor construir gráficos desse tipo com base na metodologia. APDEX (Índice de desempenho do aplicativo)

Você também pode adicionar um indicador com o número / porcentagem de solicitações com falha.







O método APDEX permite que você use indicadores em testes de regressão para comparar versões: desta forma você pode ver imediatamente o quão pior ou melhor a versão se tornou em geral. Infelizmente, este gráfico não está pronto para uso no MF LoadRunner e no Apache JMeter, mas é fácil de criá-lo usando o painel do Grafana.

Tabela de tempo de resposta

Por padrão, Gatling cria uma tabela com base em percentis, tempos de resposta médio e máximo e erros. Ele rastreia ir além do SLA (excesso de requisitos não funcionais). Normalmente, os SLAs indicam os percentis 95, 99 e a porcentagem de erros. Assim, a tabela permite obter uma avaliação rápida dos resultados do teste.



Se você agrupar consultas como transações, poderá ver na tabela a pontuação de consultas individuais e a pontuação de todo o grupo e transação de uma só vez.

Gráfico de usuários virtuais

Normalmente medido em partes e mostra como os usuários entram na aplicação, ilustrando assim o perfil de carga real. Deve-se observar imediatamente que para MF LoadRunner e Gatling, esses gráficos mostram o número de usuários virtuais, e para Apache JMeter - o número de Threads.



O gráfico é usado para controlar a exatidão da aplicação de carga. É necessário que o cenário do seu projeto corresponda ao que você enviou ao sistema na realidade. Por exemplo, se você vir grandes desvios para cima do cenário planejado no gráfico, significa que algo deu errado: um erro no cálculo, mais cópias da ferramenta de carregamento foram lançadas do que o necessário e assim por diante. Talvez não valha a pena analisar mais gráficos, já que você enviou 100 usuários a mais do que planejava, e o sistema foi originalmente projetado para funcionar com apenas 10 usuários.

Este gráfico é dividido em dois tipos:

• Usuários ativos exibe quantos encadeamentos estão atualmente ativos por segundo. Quando os threads começam e param, especialmente em um modelo de carregamento aberto, essa taxa irá flutuar durante o teste.
• Total VUsers mostra quantos threads foram iniciados e parados desde o início do teste no total. Conveniente para um modelo de carga fechada onde as roscas não morrem.

O tipo de gráfico também depende do modelo de carga:

• Modelo fechado - os usuários devem fazer login no sistema de acordo com o perfil de carga planejado. Se o gráfico mostrar quedas ou picos, isso indica que a carga não foi de acordo com o cenário calculado ou planejado e requer um estudo mais aprofundado.
• — , . , . , , / . , — .

Response Time

Na maioria das vezes medido em milissegundos - mostra o tempo de resposta às solicitações do aplicativo. O tempo de resposta não deve exceder o SLA. Este gráfico é a principal ferramenta para encontrar pontos de degradação durante o teste de carga.



Se os picos forem visíveis no gráfico, significa que naquele momento o aplicativo não respondeu por algum motivo - este pode ser um ponto de partida para novas pesquisas. O tempo de resposta deve ser uniforme, sem picos para todas as operações em toda a etapa de carga, e também se correlacionar com o arrastamento da carga. Gatling não inclui um gráfico de tempo de resposta "líquido" (médio, não agregado), ao contrário de outras ferramentas.



Além do gráfico do tempo de resposta de cada solicitação, também é conveniente mostrar uma linha com o tempo total de resposta (Tempo Total de Resposta). Sobrepondo o gráfico de carga aplicada (VU / RPS), você pode rastrear a correlação com o aumento do tempo de resposta do aumento da carga aplicada (VU / RPS). O Apache JMeter chama esse gráfico de Tempos de Resposta vs Threads.



A seguir, haverá gráficos, nos quais pode haver várias linhas, cada uma exibindo seu próprio cenário ou solicitação. Se você tiver um teste complexo com muitas operações e um perfil não linear, recomendamos que mostre apenas as consultas ou grupos de consultas mais representativos no relatório. Como alternativa, você só pode refletir solicitações que excedem o SLA / SLO, para não sobrecarregar a programação e o relatório.

Variações do gráfico

É possível uma modificação na qual os percentis de tempo de resposta são aplicados e uma linha de tempo médio de resposta para todas as solicitações é adicionada. Usar percentis aqui será mais correto, pois o tempo médio de resposta é muito sensível a outliers agudos.



Em testes de desempenho, o 95º e o 99º percentis são usados ​​com mais frequência para maior clareza. No entanto, se você observar o tempo médio de resposta, deverá considerar o desvio padrão (raiz quadrada da média).

Distribuição do tempo de resposta

Existem também gráficos excelentes que mostram a dependência da distribuição do tempo em relação ao número de solicitações.



Este tipo de gráfico é um tanto semelhante aos indicadores, mas mostra um quadro mais completo da distribuição do tempo, sem recorte por percentis ou outros agregados. Usando o gráfico, você pode definir mais claramente os limites para grupos de indicadores. O MF LoadRunner não tem tal programação.

Latency

A partir dessa métrica, um parâmetro adicional Latência (milissegundos) também pode ser distinguido - o tempo de latência (na maioria das vezes isso é entendido como Latência de rede). Este parâmetro mostra o tempo entre o final do envio da solicitação até que o primeiro pacote de resposta seja recebido do sistema.

Usando este parâmetro, você também pode medir a latência no nível da rede se o parâmetro aumentar. É desejável que tenda a zero. Este e o próximo tipo de gráfico são usados ​​principalmente para análises profundas e localização de problemas de desempenho. Este gráfico não está fora da caixa em Gatling. No MF LoadRunner, este gráfico é denominado Average Latency Graph no bloco Network Virtualization Graphs se você tiver instalado agentes de monitoramento.

Largura de banda

Semelhante à métrica acima, você pode selecionar o parâmetro Bandwidth (kilobits por segundo) - a largura de banda do canal. Mostra a quantidade máxima de dados que podem ser transferidos por unidade de tempo.



Ao alterar este parâmetro na ferramenta de carregamento, você pode simular diferentes fontes de conexões para o aplicativo: rede móvel 4G ou com fio. A versão gratuita do Gatling não possui esse gráfico, ele está disponível apenas na versão paga do Gatling FrontLine. Este gráfico está pronto para uso apenas no MF LoadRunner, está localizado no mesmo bloco que Latency e é chamado de gráfico de utilização média da largura de banda.

Gráfico de solicitação por segundo

Medida em unidades por segundo - mostra o número de solicitações que entram no sistema em 1 segundo.



O gráfico mostra quantas solicitações seu sistema pode tratar sob carga e também é o gráfico principal para a construção do relatório. Também rastreia indo além do SLA, pois com um aumento na carga ao passar do ponto de degradação ou extremo local, pode-se observar uma falha e, em seguida, um aumento acentuado. Na maioria das vezes, isso se deve ao fato de que, quando o aplicativo começa a degradar, as solicitações também começam a se acumular na entrada do aplicativo (uma fila aparece), então o aplicativo dá a eles algum tipo de resposta ou as solicitações caem por tempo limite, o que causa um aumento acentuado no gráfico - porque a resposta foi recebida.

1. VU, RPS/TPS , .
2. Response Time, , .

TPS

É medido em unidades por segundo e mostra o número de transações (pode haver muitas solicitações em uma transação) em 1 segundo.



Por exemplo, a transação "entrar na sua conta pessoal" inclui os seguintes pedidos: abrir a página principal, inserir um login, senha, pressionar o botão "enviar", redirecionar para a página de boas-vindas - por unidade de tempo. No Gatling, um gráfico só pode ser obtido usando o Grafana, pois para grupos no relatório HTML, os gráficos são construídos apenas por tempo de resposta.

Gráfico de Erros

Normalmente medido em taxa (peças por segundo) - o gráfico mostra o aumento no número de solicitações erradas. Também é conveniente medir o valor como uma porcentagem do número total de solicitações. Este gráfico rastreia SLA fora dos limites pelo número ou porcentagem de erros.



Se você sobrepor o gráfico de Tempo de resposta, poderá ver como um aumento nos erros afeta um aumento no tempo de resposta do aplicativo.



Gatling por padrão não tem um gráfico separado mostrando apenas erros. No Gatling, ele é combinado com o gráfico VU e mostra imediatamente como um aumento na carga afeta um aumento no número de erros e ajuda a detectar o limite a partir do qual o SLA é excedido ou os erros aparecem. O Apache JMeter também não possui um cronograma separado, ele é combinado com os gráficos do número de transações.

Status de respostas HTTP

Também é possível traçar a distribuição do número de erros por códigos de resposta do aplicativo em um gráfico - é conveniente usar para classificar erros.



Por exemplo, se você obteve 100% no gráfico anterior, você começa a analisar quais erros 50x são devido ao servidor não responder, ou erros 403 devido ao pool errado e os usuários não podem fazer login, se, por exemplo, você está usando o protocolo HTTP.

Inicialmente, a versão gratuita do Gatling não possui esse gráfico, ele está disponível apenas na versão paga do Gatling FrontLine. Para que o gráfico apareça na versão gratuita, você precisa reconfigurar o logback.xml para que os logs sejam coletados no graylog e construir o gráfico necessário nele.

Gráfico de rendimento

Geralmente é medido em bits por segundo. O gráfico mostra a taxa de transferência do aplicativo, ou seja, quantos dados foram enviados e processados ​​pelo aplicativo por unidade de tempo.

Geralmente é usado para análises profundas de um problema de aplicativo. Gatling só contém este gráfico no FrontLine, não está na versão gratuita.

Modificações possíveis

1. Response Time, , (Throughput). Response Time, Throughput , : - .
2. Bandwidth, , .
3. VU, , , . .

A maioria dos gráficos pode ser obtida usando o HTML Based Gatling Reports após o teste, ou configurando o pacote de monitoramento Graphite-InfluxDB-Grafana . Para exibição, você pode usar um painel pronto da biblioteca de painéis https://grafana.com/grafana/dashboards/9935 .



Ao analisar e compilar seus painéis para Gatling, você deve levar em consideração que os resultados no InfluxDB são armazenados agregados e são adequados apenas para avaliação preliminar dos resultados do NT. Recomenda-se que, após o teste, recarregue o Simulator.log no banco de dados e construa um relatório final sobre ele e procure por problemas de desempenho do sistema.

Descrição de matriz de métricas

Tudo o que descrevemos acima é apresentado na forma de um pequeno tablet resumindo todo esse conhecimento.