Tenho trabalhado com performance nos últimos meses e tive a oportunidade de parear com algumas pessoas muito experientes no assunto, e juntos até desenvolvemos um conjunto de rake tasks para execução automática de testes, o rake-jmeter, que falarei em um futuro post.
Como QA do projeto, eu fiquei encarregado de desenvolver os testes, coletar as informações de aceite, diagnosticar os principais problemas e dependências, gerar relatórios periódicos, acompanhar as melhoras e integrar os testes de performance ao build pipeline. Para isso escolhemos o JMeter, ferramenta open source, simples de usar, conhecida e muito testada na comunidade. Escolhemos ela principalmente por ter uma interface de linhas de comando que ajuda na distribuição dos testes em vários servidores ao mesmo tempo e por ser uma ferramenta com muita credibilidade.
Além do JMeter, outro elemento fundamental para o sucesso dos testes foi o NewRelic, ferramenta de monitoramento de performance em tempo real, que facilitou a visão do comportamento interno e identificação de gargalos e erros, enquanto o JMeter se encarregava de estressar a aplicação e catalogar o comportamento externo.
Abaixo algumas observações e lições aprendias ao longo desses últimos meses no fantástico mundo dos testes de performance:
1 – O tempo médio é só uma promessa
É muito comum ver critérios de aceite de performance baseados exclusivamente em tempo médio de resposta. Já presenciei muitos profissionais em listas de discussão e até materiais de referência para certificações, treinamentos ou ferramentas, citarem que tempos mágicos como quatro ou seis segundos de tempo médio seria o requisito de performance, mas aqui existe uma grande cilada.
O tempo médio de resposta é a soma de todos os tempos de resposta divididos pelo número de transações avaliadas. Por esse motivo ele é facilmente confundido com um número que define o quanto o visitante da página vai esperar quando acessar a página sob a carga experimentada durante os testes. O tempo de médio de resposta deve ser visto sim, mas como um dos fatores de aceite para o desempenho de uma aplicação web, mas nunca como o fator determinante para que essa aplicação entre em produção.
Para exemplificar como o tempo de resposta pode ser usado da forma errada, vamos supor que após executar testes em uma página web, essa página tenha nos retornado nove requests com os seguintes tempos de resposta:
5, 11, 5, 1, 5, 2, 1, 5 e 1.
Pode ser representado pelo seguinte gráfico:

Nosso product owner disse que os usuários desse tipo de sistema, normalmente abandonam o site ou perdem o foco quando estão acessando a aplicação e ela demora cinco segundos ou mais para responder. Nesse caso, nosso objetivo é que os usuários não aguardem mais do que quatro segundos e meio para ver a página completamente carregada.
Se olharmos o tempo médio das requisições acima vamos ter (5+11+5+5+5+2+1+1+1)/9 = 4 segundos. Podemos então, baseado apenas no tempo médio de resposta, dizer que os nossos testes estimam que os usuários estarão felizes usando essa aplicação, pois o tempo médio é menor que o ponto em que os usuários se frustram. Mas se observarmos de outro ângulo, podemos notar que nos nossos nove registros, apenas quatro estão abaixo do tempo de resposta desejado pelo product owner, logo, por essa outra forma de ver o mesmo requisito, podemos dizer que apenas 44% dos nossos usuários estariam verdadeiramente satisfeitos baseando-se nesse tempo de resposta de quatro segundos e meio.
O tempo médio é um indicador importante, pois ele agrega os tempos de resposta e facilita a identificação de páginas ou APIs mais demoradas, mas ele não é e nunca deve ser visto como o critério definitivo de aceite, pois ele é um número muito maleável e pode facilmente enganar o analista de performance. O ideal é observar inicialmente a variação no tempo de repostas que é representada pelo desvio padrão e a porcentagem de transações abaixo do nosso tempo máximo (leia mais logo a frente). (more…)













