Métricas e Indicadores de Performance
Muito mais do que testar um serviço, o trabalho voltado à performance também envolve analisar os resultados obtidos em um teste em busca de comportamentos no ambiente que possam ser melhorados.
Para isso, existem diversas métricas e indicadores que auxiliam na compreensão do que acontece nos bastidores quando uma requisição é realizada.
Principais Métricas e Indicadores de performance utilizados na Livelo
1. Quantidade de Usuários Virtuais
Essa primeira métrica, também conhecida como Virtual Users (VUs), representa o número de usuários simultâneos realizando requisições aos endpoints testados, então todas as métricas seguintes serão interpretadas considerando como o valor aplicado se compara com a expectativa de carga para o serviço testado.
Como padrão, estima-se que um Virtual User (VU) represente 10 usuários simultâneos. Esse padrão é uma simplificação e não o utilizamos em 100% dos casos pois a relação entre VUs e Usuários Reais pode variar significativamente a depender do contexto do teste.
Durante um teste de performance, uma quantidade de usuários é determinada através da Rampa de Usuários. Para um teste de carga, por exemplo, é comum que a quantidade de usuários aumente ao longo do teste em quatro etapas, como na imagem a seguir:
Essa métrica, em conjunto com as outras, também ajuda a estimar a quantidade máxima de usuários que um serviço consegue suportar antes de sofrer degradação. Por exemplo, em um teste, os resultados foram positivos até alcançar 75 Usuários Virtuais, portanto a aplicação consegue suportar aproximadamente 750 usuários simultâneos antes de começar a sofrer degradações de performance.
Uma variação para essa métrica também pode ser através de outra metodologia de teste, baseada na demanda em produção.
Em vez de definir um número fixo de usuários virtuais para o teste, estabelecemos metas com base nas porcentagens do pico de demanda observado em um ambiente de produção, que devem ser alcançadas durante o teste.
Por exemplo: uma rampa pode iniciar com cerca de 50% do pico de PRD, subindo para 100%, depois 150% e finalizando em 200%.
2. Quantidade de Requisições
A quantidade de requisições é uma métrica utilizada principalmente para calcular outros indicadores.
Cada vez que um usuário virtual realiza um pedido ao serviço, é contabilizada uma requisição. Essa requisição pode ser categorizada como sucesso, falha, tolerável, ideal, dentre outras a depender do contexto no qual ela é analisada. Mas, em geral, é catalogado a quantidade total de requisições de sucesso e de falha.
3. Tempo de Resposta
Outra métrica relacionada a uma requisição realizada por um usuário é o Tempo de Resposta. Essa métrica é calculada de acordo com o intervalo de tempo entre o envio de uma requisição e o recebimento da resposta do servidor.
Ele é uma boa representação da saúde da aplicação, uma vez que gargalos na infraestrutura ou no banco de dados afetam diretamente esse tempo.
Normalmente, essa métrica é usada para montar os gráficos para os tempos de resposta por requisição, além do Tempo Médio de Resposta Global.
Os três primeiros são calculados por requisição, ou seja, a cada vez que o mesmo endpoint for chamado, será guardado o tempo que a chamada demorou a ser respondida e dali tira-se o menor desses valores, o maior e a média.
Já o Tempo Médio de Resposta Global é calculado pela média de todas as requisições realizadas naquele momento do teste. Ele também possui valores máximo, mínimo e média, mas normalmente a média é a mais utilizada.
Normalmente usamos milissegundos à segundos para retratar o tempo de resposta.
4. Vazão
A Vazão é um indicador que representa a quantidade de requisições realizadas em um intervalo de tempo. Normalmente, esse intervalo é de um segundo, podendo ser visto por minuto caso as chamadas estejam demasiadamente lentas.
Com a vazão, conseguimos acompanhar a saúde da aplicação ao longo do tempo de testes. Uma vez que ela está relacionada também ao tempo de resposta e taxa de erros, como falaremos adiante, quando a vazão muda de comportamento, conseguimos aferir os limites da aplicação.
Em comportamento saudável, a vazão cresce junto da quantidade de usuários virtuais. Em tese, isso quer dizer que se mais usuários pedem algo à aplicação, mais ela responde.
Quando a vazão se mantém próxima à estagnada durante o teste, sem grandes aumentos ou diminuições mesmo com mudanças na quantidade de usuários, podemos dizer que ela está com um comportamento indesejável. Isso se deve principalmente ao fato de que se mais pessoas estão requisitando, mas a quantidade de respostas recebidas é a mesma, em algum momento haverá indisponibilidade para algumas.
Em um caso mais preocupante, é possível que a vazão diminua ao longo do teste. Nesses casos a aplicação não só chegou ao seu limite, mas ultrapassar ele causou problemas à sua habilidade de resposta, podendo levar à indisponibilidade do serviço por completo, dependendo da gravidade do impacto.
5. Taxa de Erros
Como dito na sessão sobre quantidade de requisições, as requisições podem ser separadas por diversas categorias. Para taxa de erros, calculamos as requisições do teste que falharam, seja pelo código de status da requisição, ou até mesmo por alguma verificação que mostre que a requisição não cumpriu o seu papel.
Assim, conseguimos saber da quantidade total de requisições realizadas e qual é a porcentagem de erro que ocorreu.
Esse indicador é muito usado para reconhecer estresse na aplicação, uma vez que quanto mais carga uma aplicação estressada recebe, maiores as chances de erros ocorrerem. Além disso, também é útil para reconhecer a validade do teste de performance, afinal, se um teste constantemente mostra erros desde o seu início, existe uma grande chance de haver um problema com o teste ou com o ambiente que está sendo testado.
Relações mais comuns entre as métricas e indicadores
Os dados de um teste não estão em um vácuo, onde não há interação entre eles. Cada métrica e indicador influencia nos outros de alguma forma, em interdependência. Confira abaixo algumas dessas relações.
Vazão e Tempo de Resposta
Essas duas métricas normalmente tem uma relação inversamente proporcional. Ou seja, quanto maior o tempo de resposta, menor a vazão e vice-versa.
Essa relação permite prever o comportamento do tempo de resposta ao olhar a vazão. Por exemplo, quando a vazão apresenta um comportamento saudável, é fácil esperar que o tempo de resposta se mantenha próximo à constante durante o teste. Se a vazão se apresenta estagnada ou decrescente, é esperado que o tempo de resposta aumente ao longo do tempo.
Taxa de Erros e Tempo de Resposta
Esses dois também possuem uma relação inversamente proporcional. Uma vez que a taxa de erros está alta, espera-se que o tempo de resposta fique baixo. Isso acontece, principalmente, devido às chamadas com erro não costumarem passar por todo o processo que uma requisição precisa para ser atendida, assim acabam sendo finalizadas muito mais cedo.
Vale dizer também que nem sempre essa relação é vista dessa forma. Por exemplo, caso os erros estejam acontecendo devido a um time-out, provavelmente os tempos de resposta estão altos, e não baixos. Para saber se o tempo de resposta será maior ou menor, pode-se usar a seguinte regra:
Erros com códigos de status de respostas HTTP da faixa 400 costumam reduzir o tempo de resposta e erros na faixa 500 costumam aumentar o tempo de resposta.
Quantidade de Requisições e Vazão
Nem todas as relações são inversamente proporcionais. Por exemplo, quando a vazão no teste é alta, a quantidade de requisições totais também é.
Como a vazão é uma medida de requisições por segundo, quanto maior ela for, mais requisições serão realizadas no período inteiro do teste.
Outras Métricas e Indicadores
Essas métricas e indicadores não são sempre utilizados nos testes de performance feitos aqui na Livelo, mas podem ajudar a entender melhor os resultados do teste.
Largura de Banda
Largura de Banda é uma métrica que contabiliza a quantidade de dados que está sendo usada durante a requisição. Pode ser dividida em Dados Recebidos, ou seja, os dados que a aplicação envia como resposta e Dados Transmitidos, dados que o cliente envia para a aplicação.
Ela pode ser usada para validar se o aumento da vazão é saudável ou não. É esperado que conforme a vazão aumenta, mais dados serão transmitidos e enviados. Caso esse comportamento não ocorra, pode-se identificar um gargalo no sistema.
Mediana, 90 e 99 percentil
Normalmente, durante os testes, é usado a média das métricas para determinar o comportamento padrão das chamadas no teste. Mas em alguns casos a média pode ser tendenciosa, dando a entender um comportamento que não necessariamente é o real.
Para esses casos, temos outros indicadores que podem dar uma visão mais concreta do resultado do teste.
Os percentis funcionam como uma forma de entender o alcance de performance daquela métrica. Por exemplo, em um teste, o 90 percentil pode mostrar que: “Das requisições realizadas, 90% delas conseguiram um tempo de resposta no máximo de 500 milissegundos, o que pode ser considerado positivo dependendo da necessidade de negócio.”
A mediana é a mesma coisa que o 50 percentil, ou seja, o quanto que os primeiros 50% alcançaram no resultado.
APDEX
De acordo com Paulo Andre Soares:
O APDEX (Application Performance Index) é um padrão aberto da indústria para medir o desempenho de aplicativos de software. Sua finalidade é medir o nível de satisfação do usuário, especificando um padrão para analisar e relatar o grau onde o desempenho médio atende às expectativas do usuário.
Neste artigo, não entraremos em detalhes sobre o cálculo do Apdex, uma vez que há uma abundância de informações disponíveis na internet a respeito desse tema. Nosso foco principal será o propósito fundamental que nos fez optar pelo uso do Apdex: categorizar e apresentar informações de forma acessível. Esta abordagem simplifica a transmissão da qualidade do desempenho de um serviço.
Abaixo, um exemplo de como aplicamos a classificação com base no Apdex após a execução de testes de desempenho automatizados. Isso explicita e nos ajuda a observar como essa métrica aprimora a comunicação e a apresentação dos resultados, oferecendo uma visão geral clara da qualidade do desempenho.
Conclusão
Esse artigo mostra alguma das métricas e indicadores que fazem um teste de performance entregar valor e gerar recomendações mais precisas e baseadas em fatos.
Ainda assim, essa é só uma visão geral do que pode ser encontrado e cada caso terá suas nuanças. Nenhuma das métricas e indicadores apresentados aqui residem no vácuo. Elas sempre estarão interligadas e devem ser devidamente analisadas caso por caso.
Para isso, ferramentas de Application performance monitoring (APM), como o Grafana, Dynatrace e LogDNA ajudam a explicar os comportamentos encontrados nos testes, e assim, mais assertivos serão os relatórios.
