Destilando JMeter I: Introduo e Conceitos

Dont be evil! Use o JMeter para o bem :]

H muito tempo tenho recebido pedidos de pessoas sobre como usar o JMeter e sobre como fazer testes de
performance. Apesar de no ser um full time Performance Testing Engineer, como generalista que sou, tenho alguma
experincia com performance e por sorte acabei praticando bastante esse tipo de teste usando o JMeter nos ltimos
dois anos e passei por dor de cabea o suficiente para escrever um tutorial completo com parte do que eu aprendi.
A boa notcia que vou lanar alguns posts sobre JMeter no modelo conceitos e tutorial (passo a passo explicativo)
totalmente gratuito e no comercial, e vou me esforar para que esse material seja mais detalhado e didtico
sobre JMeter na lngua portuguesa. Com sua ajuda com dvidas, feedback e compartilhamentos eu tenho certeza
que isso possvel ;]
Nesse primeiro post vamos cobrir os conceitos bsicos sobre os conceitos do teste de performance, defeitos e outras
informaes bsicas que precisamos para comear os testes de performance. Alm disso, vamos falar um pouco
sobre o projeto JMeter, sobre a interface grfica e vamos preparar o JMeter com os plugins e ferramentas mnimas
para executarmos load tests, stress tests e soak tests com profissionalismo. Ainda vamos ter uma viso geral dos
relatrios, configuraes e parmetros que podemos usar atravs da UI do JMeter. (Sim muita coisa e esse mais
um dos posts gigantes do bugbang.com.br :p)

Exemplo
de grfico de Tempo de Resposta por Tempo do JMeter [13]
Testes de performance sobre tempo de resposta?

Quando falamos em testes de performance, sempre vem a cabea medir o quo rpido a resposta de uma pgina,
mas testes de performance podem ir muito alm disso.
A Microsoft define teste de performance como:
a investigao tcnica feita para determinar ou validar a velocidade, escalabilidade e/ou estabilidade caractersticas
do produto sob teste. [2]
A wikipedia tem uma definio que eu gosto muito:

testes executados para determinar como um sistema performa em termos de responsivilidade e escalabilidade sob
uma carga particular.
e faz um adendo:
tambm investigar, medir, validar ou verificar outros atributos de qualidade do sistema, tais como a escalabilidade,
confiabilidade e uso de recursos.[1]
Eu gosto de definir que testes de performance so:
Teste onde submetemos aplicaes a cargas e condies especficas por tempo determinado afim de observar e
avaliar os diferentes comportamentos que essas condies e cargas vo proporcionar.
Esse comportamento pode ser observado de vrias maneiras e o teste de carga pode ter como sada defeitos de
performance (timeouts, tempo de resposta abaixo da expectativa, problemas de I/O, etc.), funcionais (falha no
mecanismo de caching, inconsistncias matemticas ou de dados, etc), estruturais (armazenamento, memory leak,
corrupo de dados, problemas de rede ou load balancer, etc) e de segurana (exposio de dados, exposio de
stack traces, etc). Ou seja, o simples fato de uma aplicao ter um tempo de resposta abaixo de um valor estipulado
pelo negcio no significa que essa aplicao tem qualidade quando submetida as condies e cargas dos nossos
testes.
Indicadores de performance

De acordo com Ian Molyneaux em seu livro The Art of Application Performance Testing[3], existem basicamente
quatro indicadores de performance em aplicaes que podem ser classificados em dois grupos:
Indicadores orientados a servios

O primeiro grupo orientado a servios, (que tambm podemos chamar de fatores de percepo externa ou que
afetam o usurio final) define o quo bem ou no uma aplicao prov seus servios para seu usurio final. Esses
indicadores so:
Disponibilidade

A disponibilidade a capacidade de uma aplicao manter-se operando sobre a carga, mesmo aps muito tempo.
Usualmente escutamos pessoas falando sobre aplicaes 24/7 ou de alta disponibilidade, isso significa que essa
aplicao no pode parar.
O custo de algumas aplicaes quando paradas pode ser chegar a milhes em questo de minutos, especialmente
em momentos crticos, quando o nmero de acessos acima do normal. Um exemplo desse momento a Black
Friday, uma sexta feira especial nos Estados Unidos onde todos os comerciantes do descontos significativos. O
nosso teste soak (ver mais a frente) um timo exemplo de como avaliar o comportamento da aplicao sob uma
determinada carga durante horas ou dias e em alguns casos tambm verificamos esse indicador nos testes de
estresse.
Tempo de resposta:

O Tempo de resposta o indicador mais conhecido e cobrado. O tempo de resposta o tempo que a aplicao leva
para dar o feedback apropriado para o usurio final.
Esse indicador importante porque mesmo que a aplicao tenha alta disponibilidade, se ela no responder dentro
do tempo esperado pelo seu usurio ela pode ser rejeitada por ele, abrindo oportunidades para concorrentes, mesmo

que os produtos desses concorrentes sejam inferiores em termos de funcionalidade. Alm disso, algumas aplicaes
tem tempos mximos de resposta por contrato, como acontece com algumas apis de cartes de crdito. Usualmente
medimos esse indicador em todos os programas de threads (ver a frente), embora no tenha muito valor durante o
teste de estresse.
Indicadores orientados a eficincia

O segundo grupo o orientado a eficincia, (que tambm podemos chamar de fatores de percepo interna ou de
natureza arquitetural) definem o quo bem ou no a sua aplicao est utilizando os recursos.
Vazo

Mais conhecido como Throughput, a vazo a capacidade de a aplicao ou parte dela executar uma operao
repetidamente em um perodo de tempo. Ou seja, podemos exemplificar o throughput de uma pgina como a
quantidade de vezes que conseguimos receber uma resposta completa dessa pgina por segundo.
Esse nmero importante porque define a capacidade da aplicao. Quando falamos em usurios, devemos fazer
estudos entender o quanto esses usurios esto acessando essa aplicao ou pgina, para ento definir qual ser a
nossa carga. Esse nmero importante para todos os nossos testes, mas ele usado em sua essncia para os
testes de carga, onde a carga o nmero de usurios que podem reproduzir o throughput esperado em produo.
Utilizao de recursos

Um aspecto muito importante para entender o comportamento de uma aplicao o quanto essa aplicao necessita
dos recursos computacionais para realizar as tarefas necessrias. Esses recursos so vastos e podem afetar
diretamente os demais indicadores ou mesmo outros fatores, como custo de hardware, custo de banda de internet,
etc.
Todos esses indicadores devem ser avaliados juntos, justamente por afetarem uns aos outros de diversas formas. Por
exemplo, quando a sua aplicao consome muito recurso, ou quando o recurso est abaixo do necessrio, ela
consegue processar menos requests, logo o throughput dessa aplicao reduzido. Se ela no consegue responder
todos os requests que ela respondia antes, vai existir uma lentido do sistema (tempo de resposta alto). Os usurios
vo comear a atualizar a pgina e fazer novos requests, o que vai consumir mais recursos e diminuir ainda mais o
throughput e aumentar o tempo de resposta, at um momento em que a aplicao pode entrar em colapso e perder
disponibilidade. (Sim, isso cincia e emocionante)
Para entender um pouco mais sobre esses indicadores, recomendo a leitura do livro The Art of Application
Performance Testing citado anteriormente, ou do blog post 12 Lies aprendidas em Testes de Performance Server
Side.
Schedules mais usados no mercado

Diferentes livros falam sobre diferentes modelos de teste de performance, e inclusive usam diferentes nomes para
esses modelos. Vamos usar nosso vocabulrio baseado no que vamos aplicar na prtica, logo vamos usar termos
aderentes ao JMeter. O que o jmeter chama de Programa de Threads (Threads Schedule) basicamente uma
estratgia para a execuo de testes.
Como veremos a frente, usaremos um plug-in que vai nos proporcionar usar esse programa de forma bem intuitiva,
relacionando tempo e threads. O tempo tempo determinado em segundos, enquanto as threads o nmero de
usurios virtuais disponveis. Os schedules mais usados so o teste de carga, o teste de pico, o teste de estresse e
o teste de continuidade*.

* No achei uma traduo adequada para soak test.

Modelos
de schedules mais adotados de testes de performance
Load Test ou Teste de Carga:

A linha azul clara representa o teste de carga que pode ser considerado o modelo de teste onde submetemos uma
aplicao a uma carga determinada e observamos o seu comportamento. A carga submetida neste teste deve ser a
carga esperada em produo, para que possamos avaliar os indicadores de performance e ter uma viso antecipada
dos problemas e riscos que estamos propensos a sofrer na entrada em produo, sua continuidade aps um
determinado perodo ou mesmo de acordo com nossas ultimas modificaes.
Peak Test ou Teste de Pico:

Muitas literaturas gostam de dizer que o peak test uma variao do load test onde avaliamos os mesmos
indicadores, mas submetemos a carga do site a um momento de pico, como por exemplo a black friday que citamos
anteriormente. Para isso usamos a nomenclatura Nominal Load Test, quando usamos o teste de carga com a carga
normal e Peak Load Test para os momentos em que executamos a carga aumentada para simular pico de demanda
da aplicao.
Eu separei os dois testes, pois no meu ponto de vista, na maioria das aplicaes no esperamos que os momentos
de pico tenham os mesmos comportamentos e os mesmos resultados que temos em dias normais. Para esses
momentos normalmente pensamos em estratgias como elasticidade dos nossos recursos de forma a garantir que a
aplicao continue performance de forma satisfatria.
Stress Test ou Teste de Estresse:

O teste de estresse por sua vez assume uma caracterstica muito mais focada em segurana do que em performance
no meu ponto de vista, tanto que o conceito de teste de estresse no fala sobre performance ou sobre carga, mas
sim sobre exercitar o sistema sob condies hostis ao seu funcionamento, o que no exclui carga exageradas, mas
inclui volume excessivo de dados, restries de hardware ou software, sob ataques de segurana como spidering,
etc.
Para executar um teste de estresse usando ferramentas de performance como o JMeter, podemos usar o programa
de threads representado pela linha vermelha, em que aumentamos a carga progressivamente at o momento* em
que a aplicao comea a sofrer com essa carga e finalmente cai ou falha**.

* Existem literaturas e pessoas que dizem que existe ainda um outro teste semelhante ao teste de estresse, que visa
entender aonde o ponto de maior resistncia da aplicao.
** Um outro ponto interessante para avaliar o ps teste de performance, para avaliar a recuperabilidade e
integridade fsica dos dados, configurao e servidores.
Soak Test:

O Soak test (ou teste de continuidade), representado pela linha verde no nosso exemplo, um teste que visa usar
uma carga prxima a esperada em produo, mas manter essa carga por um longo perodo de tempo, que pode
chegar a semanas dependendo da necessidade da aplicao. Esse teste exercita o sistema de uma forma bem
diferente e capaz de identificar falhas que no eram pegas antes, como por exemplo um memory leak resultante de
uma garbage collector mau configurada ou mesmo uma restrio de banda pelo seu provedor .
Sobre a nomenclatura

Eu particularmente me preocupo muito mais com o entendimento dos conceitos e dos diferentes teste de
performance, por isso no me preocupei em dedicar tanta ateno nem referncias para esses testes neste primeiro
post. Eu tenho certeza que se pesquisarem vo encontrar outros nomes, mas de uma certa forma os conceitos so
bem aceitos na comunidade e na literatura. A mensagem que eu quero passar aqui o que cada teste faz e quando
usar esse teste, fique a vontade para mudar a nomenclatura na sua empresa.
Cenrios, Volumetria e Ambiente

Eu diria que o sucesso de um teste de performance est to relacionado ao balano entre o ambiente, os cenrios
escolhidos e os dados criados quanto h definio da carga correta. Eu digo isso porque em certos casos voc pode
aumentar a carga vezes dez, que ainda assim vai ter um resultado muito melhor que que se tiver o volume de dados
dobrado por exemplo.
Cenrios

Google Analytics como ferramenta para definir cenrios e distribuio

de carga

Os cenrios podem variar de um simples acesso em uma determinada pgina, para um cadastro de um novo usurio
ou mesmo upload de dados, imagens ou informaes. Esses cenrios devem ser elaborados pensando em situaes
semelhantes as reais, para isso pense que a home page, assim como todas as outras landing pages, vai ter mais
acessos, que funcionalidades como de resetar senha ou de efetuar cadastros tambm vo precisar de uma ateno
especial.
Embora seja importante testar cada uma dessas funcionalidades individualmente, muito importante reproduzir um
cenrio prximo ao real, executando um teste de integrao de performance similar ao esperado em produo.

A imagem ao lado de um grfico de comportamento gerado pelo Google Analytics, que pode ser uma tima fonte de
recursos caso esteja construindo novos testes para uma aplicao legada em processo de reconstruo.
Volume

O volume de dados deve ser planejado para o que espera-se da aplicao, no somente no momento do release,
mas tambm quando ela estiver produzindo e funcionando a todo vapor. Segundo o livro The Art of Application
Performance Testing[3], importante pensar nesse volume para o dia do release, seis meses depois do release, um
ano depois do release e dois anos depois do release.
Essa uma das partes mais cincia do planejamento, porque temos que estimar o volume de dados que vais usar
para cada um dos modelos de dados do sistema, ou seja, se estivermos pensando em uma loja virtual temos que
prever qual o nmero de lojas, quantos produtos, quantos usurios, quantas peas de cada produto, quantas
vendas, etc., para cada um dos nossos marcos de teste.
Ambiente

quase impossvel reproduzir o ambiente de produo, no s porque caro, mas tambm porque vrios detalhes
s podero ser implementados ou configurados, como dados de acesso a cartes de crdito, servios de mailing, etc.,
por isso perseguir o ambiente de produo pode ser um tiro no p.
Ao invs disso voc pode entender a sua arquitetura e tentar replic-la de uma maneira reduzida em um ambiente
controlvel. Se a sua aplicao e infra estrutura foram desenvolvidas para escalar horizontalmente (atravs da adio
de novas mquinas), e seu ambiente de produo tem vinte mquinas por exemplo, voc pode simular um micro
ambiente de produo com duas mquinas e imaginar que seu teste vai escalar algo em torno de seis a oito vezes.
Performance no exatamente linear, portanto tenha sempre uma margem de segurana para fazer esse calculo.
Caso o seu sistema tenha sido desenhado para escalar verticalmente (atravs da adio de recursos como memria
e CPU ao(s) servidor(es)) voc pode simular um ambiente parecido com o de performance mas com a infra estrutura
mais bsica.
O mais correto fazer experimentos para calibrar essas mtricas. Caso tenha a oportunidade de executar uma
ferramenta de acompanhamento da performance em produo, como o New Relic [9], use-a para entender qual a
relao entre a performance de produo e do seu ambiente emulado.
Defeitos que podemos encontrar

Como comentado anteriormente podemos encontrar dezenas de defeitos durante os testes de performance. Vou
tentar sumarizar alguns dos tipos de problemas que j encontrei com uma breve descrio, exemplo e problemas
resultantes desses defeitos:
Tempos de Resposta Baixos: O problema clssico que encontramos mais frequentemente associado a teste de
performance. Quando o tempo de resposta de um alvo de teste de performance est abaixo do tempo esperado pelo
Business, podemos dizer que esse um problema e precisamos estud-lo. Bem possivelmente outros problemas
listados abaixo tambm podem influenciar nessa lentido.
Timeouts: Quando o tempo de resposta fica mais lendo do que a API est configurada para suportar ele pode
comear a retornar erros de timeout, quando o servidor no mais capaz de processar o request e simplesmente
devolve um erro. Esse tipo de problema quando no tratado pode ser raiz para outros problemas como a exposio
de dados ou de stack traces.

Falha no mecanismo de caching: Testes de performance tambm podem ajudar a identificar quando um mecanismo
de caching no est funcionando. O Mecanismo de cache pode por exemplo ter o objetivo de armazenar o contedo
processado inicialmente na memria RAM de um servidor configurado para ser caching server e em seguida devolver
para os requests seguintes o contedo j armazenado em memria. Testes de performance podem ajudar a entender
se esse cache est funcionando corretamente.
Erros de load balancer: Outro teste que podemos fazer monitorar todos os servidores que estamos usando para
balancear a carga (incluindo o prprio node balancer que deve distribuir a carga entre os demais servidores) e em
seguida executar testes de performance e avaliar qual o throughput que est chegando em cada um e qual o
consumo de recursos, identificando por exemplo quando o load balancer no estiver calibrado.
Memory Leak: Como o teste de performance pode executar uma sequncia de operaes milhares de vezes, ele
tambm pode nos ajudar a identificar se alguma rotina no est tratando a memria que no mais necessria, ou
seja, se o sistema est desalocando memria na hora certa. Caso no esteja, vamos ver um crescente consumo de
memria mesmo quando terminamos as tarefas e a memria poderia voltar para o pool de memria livre.
Perda de Dados: Uma quantidade excessiva de requests pode causar problemas como bloquear uma tabela, incluir
demasiados registros ao mesmo tempo em um repositrio, substituir arquivos se por algum motivo estranho como por
exemplo se usamos o timestamp para gerar o nome ou diretrio desse arquivo, etc. Como testes de performance
podem executar tarefas de uma maneira bem rpida, principalmente em sistemas distribudos, esses tipos de
problemas podem aparecer durante os nossos testes.
Exposio de Dados: Em alguns casos o teste de performance pode gerar erros 50x que espoem detalhes como
mecanismos de cache, dados do servidor, stack trace com informaes do banco de dados entre outras informaes.
Todos os problemas acima podem existir em sua aplicao, e normalmente no paramos para pensar sobre todos
eles e muito menos sobre como encontr-los ou investig-los no dia a dia. O teste de performance pode nos ajudar a
encontrar esses problemas de forma mais fcil. Aliado a uma ferramenta de monitoramento de erros como o New
Relic [9] podemos guardar o log desses erros e investigar depois que terminarmos o teste. Atravs do log podemos
ento criar testes especficos para essas situaes e evitar problemas mais graves em produo.
Mo na massa com JMeter

O Apache JMeter (aka JMeter) um software livre de cdigo aberto para gerao automatizada de carga criado e
mantido pela Apache Software (http://www.apache.org/) como parte do projeto Jakarta [12]. Por ser uma ferramenta
madura (criada em 2001 e RC em 2007) ela tem se mantido como a primeira ferramenta que nos vem a cabea
quando falamos de testes de carga ou performance.
Escolhi o JMeter como ferramenta por alguns motivos. O primeiro motivo que o JMeter uma ferramenta livre e
open-source, ou seja, no s gratuita como tambm tem o cdigo disponvel caso queiramos mudar alguma coisa,
conferir alguma mtrica, desenvolver uma nova funcionalidade, etc., assim todos podemos baixar e usar sem
nenhuma restrio. O segundo motivo que ela 100% baseada em Java, dessa forma no importa qual o sistema
operacional voc esteja usando, o comportamento funcional vai ser o mesmo*. O terceiro motivo que ele a
ferramenta mais usada no seu seguimento, inclusive nas nossas comunidades como o #DFTests [ 4]. O quarto motivo
que o JMeter oferece uma interface de linhas de comando muito bem organizada, o que permite que ele seja usado
por mquinas (servidores de integrao continua por exemplo) e pode ser distribudo em clusters para escalar com
muita facilidade.

Caso ainda tenha dvidas consulte o wiki oficial da ferramenta [11]. Para saber mais sobre outras ferramentas de
teste de performance voc pode consultar o blog Software Testing Help no post Top 15 Performance Testing
Tools Comprehensive List of In-Demand Tools with Download Link [8]
* Diferentes sistemas operacionais podem tratar as threads de forma diferente. Sistemas baseados em Unix tendem a
trabalhar melhor com threads e processos computacionais do que outros sistemas operacionais.
Como instalar o JMeter?

O JMeter no uma ferramenta para instalar. Voc precisa execut-lo a partir de um terminal ou usando uma bat
caso esteja usando Windows. Particularmente, eu sugiro que use um sistema operacional baseado em Unix como
Linux ou OSX para seguir esse tutorial e mesmo para rodar os testes na sua empresa.
Para executar o JMeter voc precisa de ter o java instalado no seu computador, para isso v at o site da Oracle [ 7] e
baixe a verso mais recente do JDK pasta baixar a verso mais recente no site da Apache [ 5], extrair os arquivos e ir
at a seguinte pasta:
$ jmeter/bin/
Neste diretrio, execute o comando:
$ ./jmeter
Turbinando o JMeter

Agora voc deve ver a interface grfica do JMeter. Nesse ponto, feche o JMeter e faa o download dos plugins
JMeterPlugins-Standard-1.1.1.zip,
JMeterPlugins-Extras-1.1.1.zip,
JMeterPlugins-ExtrasLibs-1.1.1.zip [9].
Extraia os arquivos e mova os arquivos .jar para dentro da pasta jmeter/lib/ext, ou siga as instrues no link [9].
Feito isso, vamos ter novos recursos que sero utilizados neste e nos prximos posts, como o Ultimate Thread Group,
o CMDJmeter e algumas bibliotecas para tratar dados por exemplo.
Entendendo os componentes bsicos

Arvore de Componentes

O JMeter tem uma arvore de componentes bem intuitiva que fica a esquerda na interface grfica. Essa rvore de
componentes fornece as ferramentas necessrias para escrever testes, criar verificaes, cuidar de situaes
especiais como cookies e controles de tempo, controlar e distribuir o fluxo de execuo das threads, gerar relatrios,
etc.
Nesta sesso vamos entender pra que cada um desses componentes utilizado e quais so suas principais opes:
Plan

O Plano um elemento nico e requerido para qualquer atividade dentro do JMeter. Esse elemento agrupa todos os
outros elementos e controla a execuo de thread groups.
No existem muitas opes para falarmos nesse tutorial inicial, mas uma caracterstica muito importante desse
componente a capacidade de armazenar variveis globais, chamadas de User Defined Variables. Dentro desse
elemento podemos armazenar um grande nmero de variveis que podem ser usadas livremente em todo o script
para flexibilizar a nossa implementao ao armazenar dados que variam de acordo com o ambiente sob teste, por
exemplo strings de conexo com bancos de dados, url do servidor, etc.
Schedule Thread Group

O Schedule Thread Group o componente que controla o nosso teste. Ele tem o poder de controlar a execuo e por
esse motivo inclumos o Ultimate Thread Group mais cedo no nosso tutorial, pois dessa forma estendemos o nosso
controle para tempo de execuo e no somente para nmero de execues.

Exemplo
do uso do Ultimate Thread Gorup

O exemplo acima representa um teste que deve aguardar dez segundos para comear (Initial Delay, Sec), iniciar uma
thread por segundo (Startup time igual ao nmero de threads), usar as vinte e cinto threads durante 20 segundos
(hold Load for, sec) e finalmente desligar uma thread por segundo (Startup time igual ao nmero de threads). O
Ultimate Thread Group disponibiliza uma viso grfica do nmero de threads, que inclusive inspirou o meu grfico que
exemplifica os programas de thread.

Voc pode ainda controlar o teste em caso de falha, desligando a thread que encontrou o problema, abortando o
teste, ignorando a falha, ou, como no exemplo acima, simplesmente abortando essa execuo dessa thread, e
comeando um novo teste com essa thread na configurao Action to be taken after a sampler error.
Logic Controllers

Os controladores lgicos so a maneira de direcionar os seus testes de performance para executar uma determinada
sequncia ou fluxo de eventos, tomar decises baseadas em dados colhidos durante o teste, agrupar samplers ou
outros elementos, etc.
O JMeter no uma ferramenta de testes funcionais, embora muitas pessoas o usem como tal e mesmo no plano de
testes citado acima ele tenha uma opo para Emular testes funcionais de software. Algumas pessoas, assim como
eu, no acham interessante emular testes funcionais em uma ferramenta como o JMeter e por essa razo evitam usar
os controladores lgicos disponveis (no o meu caso). Mas eu posso listar uma vasta quantidade de situaes
onde eles so muito teis, e aqui vo alguns exemplos:
Simple Controler: Um controller que s agrupa elementos, ajudando voc a manter o seu teste sempre organizado e
segmentado.
Once Only Controller*: Existiro dezenas de situaes onde voc vai querer executar algum comando uma nica
vez, para isso voc precisaria sair do seu thread group, criar um thread group com uma thread s, e continuar o seu
teste com outro thread group que permita o seu teste a continuar como anteriormente. Para evitar todo esse trabalho,
existe um controlador de fluxo chamado Execute uma s vez, que independente da quantidade de threads vai
executar somente uma vez tudo que estiver agrupado com ele.
Throughput Controller: Outro controlador muito til que tem o poder de decidir, aleatoriamente, quanto ao percentual
ou mesmo nmero absoluto mximo de execues que um determinado grupo de componentes vai receber. Esse
controlador muito til quando temos que fazer um teste de integrao de performance** e por isso precisamos
distribuir a carga em propores diferentes para cada um dos elementos sob teste.
Random Order Controller: Por default o JMeter executa seus testes como um script, ou seja, de cima para baixo.
Caso precise executar alguns elementos em ordens aleatrias voc pode usar esse controller.
Random Controller: Diferente do controller citado acima, o Random Controller no executa todos os itens sob ele de
forma randmica, mas escolhe um elemento de forma randmica e o executa. Uma situao que eu usei esse
controlador foi em um caso onde no meu projeto eu tinha que simular uma fila de requests aleatrios para algumas
apis, mas segundo a especificao esse requests deveriam ser feitos um por um de forma irregular. Setei uma thread
e coloquei esse controler sobre todos os meus samplers e voila.
Controladores de repetio e condio: Ainda temos os controladores para funes bsicas de lgica de
programao, como o IF, LOOP, FOR EACH, SWICH e WHILE. No vamos entrar em detalhes agora ainda porque as
funes de cada um so bem conhecidas por todos aqui.
* O Once Only Controller no tem a capacidade de executar uma s vez para clusters. Caso esteja rodando mais de
um JMeter ao mesmo tempo usando o client server JMeter, ele executar uma vez o Once Only Controller para cada
mquina com o script.
** Teste realizado com vrias pginas ou apis ao mesmo tempo, para definir o comportamento de um ou mais desses
itens quando outros itens sofrem um grande nmero de acessos ao mesmo tempo.
Timers

Vrias vezes temos que usar pausas para execuo de um script, por exemplo quando precisamos emular um
determinado thinking time*. Para isso temos alguns timers como o constant timer que espera por um tempo absoluto
em milissegundos ou o uniform random timer onde informamos uma variao entre X e Y para a nossa pausa, alm
de outros timers.
* Thinking Time o nome do tempo que determinamos em alguns scripts funcionais e no funcionis para o tempo
que o usurio espera antes de realizar uma nova operao, por exemplo lendo, movendo o mouse, ou mesmo
pensando sobre o que vai fazer.
Samplers

Samplers so onde determinados a forma como vamos acessar o alvo de testes, com quais dados vamos acessa-lo e
quem o alvo dos testes. Cada sampler corresponde a uma* pgina, um servio, uma consulta sql, etc. Um sampler
submetido a um Thread Group, mas um Thread Group pode ter vrios samplers diferentes. Dessa maneira que
podemos usar um mesmo programa de performance para rodar os testes de integrao, quando avaliamos os
comportamentos de pginas quando seus pares esto sob a mesma carga simultaneamente.
* Uma pgina pode consumir dezenas de servios, incluir outras pginas, assets, consultas sql, etc., logo essa
afirmao diz respeito a um request para algum elemento, desconsiderando o seu comportamento interno que pode
fazer novas chamadas.

HTTP
Request Sample

Os campos bsicos so:

Name: Um nome descritivo e intuitivo sobre a pgina ou servio sob teste deste sampler.
Server Name or IP: O server ou IP do server, por exemplo bugbang.com.br, google.com, thoughtworks.com, etc.
Port Number: A porta usada, comumente 80 para pginas web. Voc pode conseguir essa informao com os
desenvolvedores, olhando no cdido ou tentando acessar pelo browser, ferramenta de requisies SOA, etc.
Method: Para a maioria das pginas vai ser GET, mas deve ficar atendo para formulrios que normalmente usam
POST.

Path: O que vem depois do servidor, por exemplo quando vamos para a pgina Sobre deste blog, ele nos direciona
para a rota /about/.
Parameters: caso trabalhe com query string*, com parmetros no POST, ou com quaisquer informaes que devem
ser parametrizadas voc vai ter que inclu-las aqui.
O exemplo acima faz uma consulta para a pgina sobre deste blog, usando a porta 80 que a padro e sem passar
nenhum parmetro. A opo de Follow redirects basicamente redireciona automaticamente quando recebemos uma
resposta do tipo 30x. No se preocupe com resposta HTTP agora, vamos falar disso em futuros posts dessa
sequencia
* Query String so parmetros que passamos pela URL como por exemplo os parmetros de busca do google para a
busca Camilo Ribeiro http://www.google.com.br/#q=camilo+ribeiro
Preprocessors e Postprocessors

Esses elementos so usados para executar aes antes (preprocessors) ou depois de um sampler (postprocessors).
Eles so importantes para ajudar o engenheiro de testes de performance a criar condies especiais ou a executar
aes dentro de um sampler.
Preprocessors: Um exemplo de bom uso de um preprocessor
Postprocessors: Um timo exemplo do uso de postprocessor quando temos uma aplicao que usa um CSRF id
Token* (Cross-Site Request Forgery). Por definio, esse mecanismo evita que mquinas visitem ou postem
informaes em aplicaes web. Para isso frameworks como o Rails implementam em seus formulrios um campo
oculto com um hash que postado pelo prprio framework garantindo que no existe uma mquina por trs.
Obviamente, como tudo do lado cliente manipulvel, usualmente realizamos um get no formulrio e usamos um
postprocessor como o Regular Expression Postprocessor para acessar o HTML desse get, armazenar o contedo
em uma varivel e mais tarde submeter esse valor como parte dos parmetros do nosso post, simulando o
comportamento do framework. Falaremos sobre como burlar esse tipo de verificao de segurana em um post
futuro.
Asserssions

Assim como testes funcionais, podemos usar mecanismos de verificao para ter certeza que o nosso teste est
funcionando corretamente. Essas verificaes servem basicamente para garantir que est tudo ok e que podemos
continuar os nossos testes e principalmente para evitar falsos positivos.
Por padro, o JMeter considera respostas 20x e 30x como sucesso e respostas 40x e 50x como falha, mas ambos os
casos podem no ser erros em determinadas situaes. Imagine que est executando um teste e o objetivo realizar
um post para logar na aplicao antes de continuar os testes, mas por algum motivo o usurio e senha do script de
teste de performance est errado. A aplicao vai tratar esse problema e retornar a mensagem de no login com o
cdigo 200, ou seja, o nosso teste no deveria continuar pois existe um problema, mas para o JMeter est tudo bem
pois tivemos uma resposta 200 Ok. Ou (para os paranoicos) se estivermos testando a nossa pgina de Page Not
Found, na verdade estamos esperando uma resposta 404 Page Not Found.
Para esses casos temos verificaes que tem o poder de mudar o resultado de um script avisando ao JMeter que
est tudo bem (ou no). Os principais modelos de verificaes que temos so:
XPath: xpath classico para pesquisar no response por algum texto.

Duration Assertion: Voc vai ter um relatrio no final, mas se quiser falhar um request por ultrapassar um
determinado tempo de resposta voc pode usar uma verificao de quanto tempo ele est levando para terminar de
carregar.
Response Assertion: Voc pode definir qual o cdigo HTTP correto para uma pgina, dizendo ao JMeter que no
deseja um 200, mas sim um 404 como no nosso exemplo anterior.
Eu quero desencorajar voc se pensar em usar o JMeter para testes funcionais. O JMeter no a melhor ferramenta
para isso e nunca vai ser. Apesar da caracterstica de verificao dele, ele no desempenha esse papel da melhor
forma. Use essa ferramenta para testes de carga como estamos descrevendo aqui.
Listeners

Os listeners so os nossos relatrios. So vrios relatrios e com a incluso do nosso Ultimate Thread Group
ganhamos alguns novos. Aqui eu vou falar sobre os mais teis na minha opinio:
View Results in a Tree

Listener View Results in a Tree

Esse , na minha opinio, o amigo nmero um durante a elaborao do script de performance. Esse Listener captura
o request realizado (URL, parmetros, etc.), o response do servidor (tempo de resposta, latncia, cdigo HTTP, etc) e
ainda carrega o HTML/Javascript/JSON/XML gerado pelo request. Isso d ao engenheiro de performance uma
ferramenta essencial para debuggar o script e entender Porque ele no foi de acordo com o planejado.
Alm disso ele marca de verde e vermelho os requests de acordo com o resultado de sucesso ou falha. Depois que o
script est pronto voc pode tambm avaliar os requests realizados um a um caso seja necessrio, por exemplo
tentando entender porque um determinado request foi muito mais rpido ou muito mais lento que os demais.
Summary Report:
O sumrio outra ferramenta bem poderosa. Ele sintetiza algumas das informaes mais valiosas do teste e agrega
em uma s planilha de informaes. Aqui podemos coletar informaes de cada sampler como tempos mximo e
mnimo, throughput, tamanho da resposta, quantidade de requestes realizados, tempo mdio e desvio padro.

Sumrio
do teste de performance

Eu gosto muito de usar esse relatrio como uma primeira viso do resultado. Caso identifique que alguma informao
est estranha, como por exemplo um tempo mnimo de 2 milissegundos e um tempo mdio de 3 segundos, e ento
voc pode se aprofundar e consultar o request de forma individual pelo Results in a Tree
Respose Time over Time

Response Time over Time

O relatrio de tempo de resposta por tempo de execuo pode te mostrar dados interessantes sobre o
comportamento diversificado das suas pginas/servios durante o tempo de uma forma grfica. Ele tambm tem a
capacidade de te mostrar de uma maneira bem simples se voc teve um outlier (valor atpico) tanto para cima quanto
para baixo.
No nosso exemplo a esquerda, podemos ver que em algum momento um request vermelho (About page) respondeu
com mais de 2/7 segundos. Pelo relatrio podemos ver que essa pgina estava numa tendncia de estabilidade
mantendo seus requestes a menos de 1.2 segundos.
Response Time Percentils

Response Time Percentiles

Um dos relatrios menos lembrados, mas na minha opinio um dos mais importantes quando falamos de previso e
anlise de tempo de resposta de uma aplicao.
Esse relatrio nos da uma viso grfica dos percentis por pgina, ou seja, ele enfileira em ordem crescente e
cumulativa todos os tempos de resposta e cria uma linha no grfico que aumenta no eixo X de acordo com a
porcentagem e aumenta no eixo Y de acordo com o tempo de resposta. Em outras palavras, ele nos permite saber
que 90% das nossas transaes para a pgina About responderam com o tempo inferior a 1.8 segundos.
Essa informao muito mais tangvel do que dizer que o tempo mdio da pgina about foi de 1.029 por exemplo.
Quando falamos que o tempo mdio foi de quase um segundo, algumas pessoas assumem que a maioria das
pessoas teve um tempo de resposta de ate 1 segundo, quando na verdade elas tiveram tempos de resposta variveis
e ao mesmo tempo to baixos e to altos que o tempo fez parecer que estava baixo. Dessa maneira e com a ajuda
desse listener voc pode criar critrios de aceite mais concretos, por exemplo criando um critrio que diz que 95%
dos usurios devem receber a pgina antes de 1.2 segundos.

Hits Per Second

Hits per Second

O relatrio de Hits por Segundo tambm bem til, ele mostra na forma de um grfico o nmero de hits (transaes)
que o servidor respondeu por segundo de acordo com o tempo que o teste foi executado.
Com esse relatrio podemos identificar por exemplo, quando em um determinado tempo o servidor comea a
responder menos hits. Essa informao especialmente importante para ajudar a diagnosticar quando uma aplicao
comea a piorar o throughput ao longo do tempo durante um soak test por exemplo.
ps: Esse nmero a soma de todas as pginas e aqui no estamos avaliando o comportamento das pginas, mas
sim da forma como o servidor processa todas as transaes que estamos passando. Mais a frente vamos ver um
listener que tem a capacidade de avaliar pginas individualmente.
Response Time Over Threads

Response Time over Threads

Esse listener nos ajuda a entender a relao entre o nmero de threads como especificado para o teste e seu tempo
de resposta. Essa informao importante para entender quando uma aplicao comea a perfromar abaixo do
esperado na escala esperada para o teste de carga ou estresse por exemplo.
Para entendermos o comportamento usamos o Ultimate Thread Group, que permite aumentar e dimiinuir o nmero
de threads ao longo do tempo. No exemplo a esquerda podemos observar que existe um aumento progressivo do
tempo de resposta ao longo do nosso aumento de nmero de threads.
Em testes de estresse por exemplo, onde uma abordagem pode ser aumentar a carga indefinidamente at que o
sistema entre em colapso, esses nmeros so importantes para entendermos quando o nosso sistema comea a
apontar esse comportamento, tambm para sabermos qual o melhor momento para coletarmos os logs.
Transactions Throughput vs Threads

Transactions Throughput over Threads

Assim como o Hits per Second, esse relatrio tem como ideia coletar as informaes de throughput, mas separando
essa informao por sampler, de acordo com a imagem a direita.
Esse relatrio essencial para entender onde esto os nossos gargalos de performance durante um teste integrado
de performance.
Vamos imaginar que uma das nossas transaes esteja muito lenta. Essa transao, possivelmente, est consumindo
muito recursos do servidor, ou no mnimo est bloqueando uma ou mais das nossas threads por muito tempo,
diminuindo o throughput de todas as demais transaes. Nesse momento, esse relatrio tem a capacidade de nos
mostrar de uma forma muito simples qual essa transao, e ento podemos estudar uma abordagem especial para
observar o comportamento interno e externo dela.
Alm disso, esse relatrio tem o mesmo benefcio citado anteriormente no Response TIme over Threads, que
habilita o engenheiro de performance a entender quando o sistema (ou nesse caso at uma funcionalidade) entra em
colapso durante um teste de integrao de performance.
PerfMon Metrics Collection
Esse um coletor de mtricas do servidor automatizado. Eu particularmente gosto de verificar os dados do jeito
antigo, consultando logs, acompanhando pelo prprio servidor e usando algumas ferramentas como o New Relic que
proporciona uma viso mais detalhada, mas caso no tenha ainda uma soluo como o New Relic ou no consiga
acompanhar os logs, voc pode usar o PerfMon Metrics Collector.
Esse um listener que precisa de um setup especial. Para coletar essas mtricas precisamos que o servidor tenha
java1.6+ instalado e precisamos baixar um agente e execut-lo. Voc pode encontrar o passo a passo em ingls
aqui [10], mas caso esteja usando um servidor linux voc pode executar os seguintes comandos:
$ wget http://jmeter-plugins.org/downloads/file/ServerAgent-2.2.1.zip
$ tar -zxvf ServerAgent-2.2.1.zip
$ ./startAgent.sh

Perfmon Metrics Collector para CPU

Com esses comandos voc vai iniciar o agente que permite ao JMeter coletar informaes como consumo de
memria, de rede, de I/O, CPU entre outras. Para coletar essas informaes voc ainda vai precisar adicionar o
listener e colocar o IP da mquina e a informao que deseja coletar.
Particularmente eu gosto de instanciar um coletor para cada mtrica que vou analisar, porque como os valores so
muito diferentes, o JMeter cria umas converses malucas para manter a estabilidade da escala de cada um dos
conversores. No meu ponto de vista essas informaes so importantes o suficiente para terem ateno dedicada dos
engenheiros de performance.
Os resultados nos ajudam a entender os motivos de lentido derivados do hardware ou do consumo excessivo de
recursos computacionais. Essas informaes so importantes para avaliarmos o que est acontecendo com o nosso
servidor quando um determinado nmero de threads chega no que o negcio espera, ou mesmo para entender o
porque o nosso teste soak deu problema.
O JMeter ainda possui vrios outros listeners como o Transactions per second e Active Threads Over Time, que
podem te dar novas perspectivas sobre os resultados sob avaliao. Voc pode experiment-los a vontade para
entender quais so os mais importantes para voc nos seus testes de performance. O importante que antes de usar
qualquer um desses relatrios como uma viso definitiva, voc pense sobre o que quer medir e ento estabelea um
conjunto de mtricas.
Estamos falando somente dessas mtricas neste primeiro tutorial, mas importante lembrar que esse apenas o
JMeter, ou seja, estamos falando de uma das ferramentas que usamos dentro de um conjunto de ferramentas para
coletar informaes sobre performance. Apesar de o JMeter ter listeners e relatrios para coletar dados, a sua
principal funo ainda a de gerar carga, por isso importante ter outras maneiras de monitorar a performance da
aplicao sob carga.
Hello Performance com JMeter

Agora vamos executar o JMeter contra um servidor e ver alguns desses dados. Para isso use o ambiente que criamos
no incio deste post.
Abra o JMeter, caso esteja usando o linux, basta executar o aplicativo ou o arquivo shell script dentro da pasta bin do
JMeter, se estiver no Windows use o arquivo .bat. (lembre-se que precisa do java instalado no seu computador!)
$ ./jmeter
Agora voc vai ver o plano de teste a sua esquerda. Clique com o boto direito nele e vejas as opes disponveis.
Vamos iniciar adicionando um Ultimante Thread Group:

Passo

1:

Adicionando um Ultimate Thread Group ao nosso plano

Agora que temos o nosso plano, vamos pensar em qual programa queremos simular. Eu recomendo que simulemos
um load teste curto, somente como prova de conceito. No meu caso vou usar 3 threads para no gerar muita carga e
vou usar um intervalo de dois minutos para o teste, dividindo 30 segundos para rumpup (subida da carga), um minuto
para manter a carga e mais trinta segundos de rumpdown (descida da carga). Para adicionar essa carga temos que
usar o boto add row.

Passo 2:
Adicionando o programa que queremos usar no teste de carga

Agora que temos o programa preparado com o Ultimate Thread Group, vamos adicionar um sampler do tipo HTTP
Request clicando com o boto direito sobre o Thread Group que acabamos de adicionar, selecionando as opes
Add > Sampler > HTTP Request.

Passo 3:
Adicionando um Sampler do tipo HTTP Request ao nosso Thread Group

Nesse momento peo que voc tenha bastante discernimento para escolher um site seu* ou algum site que tenha
autorizao para emular carga contra ele. Lembre-se que podem existir implicaes legais contra tentativa de ataques
contra espaos virtuais e uma execuo de ferramentas de repetio como o JMeter pode ser considerado uma
tentativa de DoS (Denial of Service) e facilmente identificado atravs de logs do servidor com informaes do
attacker.
Para evitar esse tipo de problema, eu sugiro que voc use um apache local ou uma aplicao simples no seu
computador local, e use esse site como ataque, o que eu vou fazer nesse tutorial.
* Mesmo que o site seja seu, consulte o seu provedor para ter certeza que esse tipo de ataque permitido. Caso use
um servidor compartilhado possivelmente vai gerar problemas para outros usurios.
Caso no tenha ideia do que usar e tenha conhecimento em Node.JS, voc pode usar uma aplicao que eu criei
para testar framewoks de perofrmance chamada Hitz (https://github.com/camiloribeiro/hitz). Ela bem simples de
instalar e executar, as instrues esto na prpria pgina da ferramenta.

Passo 4:
Adicionar as informaes de Server, Port Number, Path, Method e Prameters se necessrio

Agora j estamos habilitados a rodar o teste, mas do jeito que est, no vamos saber o que est acontecendo. Para
acompanhar o teste, vamos adicionar listeners a vontade, mas eu recomendo que pelo menos o Summary Report,
Active Threads Over Time e o View Results in a Tree. Para isso clique com o boto direito no Thread Group e
ento Add>Listener.
Dica: Todos os elementos do JMeter, como os listeners, config element, timers, assertions, pre e post processors
podem ser includos no mesmo nvel dos samplers, ou abaixo de um deles individualmente. Quando eles esto no
mesmo nvel eles executam sua operao para todos os samplers e quando esto abaixo de um sampler eles s
executam sua operao para esse sampler. No nosso exemplo com um sampler s no faz diferena, mas voc pode
criar novos samplers e brincar com esses elementos, assim vai entendendo como criar diferentes cenrios de teste.

Passo 5:
Adicionar os listeners que geram os relatrios para acompanharmos o teste

Agora vamos iniciar os nossos testes de performance. Para isso basta usar o atalho control r ou ir no menu Run >
Start.

Passo 6:
Agora voc pode observar os resultados nos relatrios que adicionou.

Caso esteja usando o Hitz que eu indiquei mais cedo, voc vai observar que o nmero de requests vai aumentando
progressivamente com os hits que o JMeter lana contra o servidor no seu localhost. Voc vai poder comparar
tambm os resultados

Respost
a do Hitz aos hits provocados pelo JMeter em tempo real
Concluindo

O JMeter uma ferramenta fantstica, e esse tutorial s te mostrou o bsico das suas configuraes e execuo. O
JMeter tem um poder extraordinrio quando usado em conjunto com outras ferramentas ou linguagens de
programao, como por exemplo shell script, ruby, virtualizadores, servidores de integrao contnua, apis de cloud
computing, etc.
Nas prximas lies voc vai aprender mais sobre como escrever scripts de performance usando as ferramentas que
conheceu hoje, como executar o JMeter de mais de uma mquina ao mesmo tempo e como rodar o JMeter usando
linhas de comando, mas no se desespere! muito mais simples do que voc imagina! Alm disso vamos integrar
o JMeter com o Jenkins e mostrar como voc pode manter seus testes de performance rodando todo o tempo e ser
avisado quando alguma coisa est ficando diferente.
Espero que esse tutorial para escrever um pequeno teste de performance com JMeter tenha sido til e simples de
acompanhar para voc. Caso tenha algum feedback, sugesto de melhoria, correo ou informao que poderia estar
aqui, entre em contato comigo que vou melhorar/corrigir/adicionar com prazer.
Caso tenha gostado desse tutorial e queira ver o novo tutorial que explica como criar testes com JMeter, compartilhe e
vamos avanar para o prximo nvel
[1] http://en.wikipedia.org/wiki/Software_performance_testing (acessado em 12 de julho de 2013)
[2] http://msdn.microsoft.com/en-us/library/bb924357.aspx (acessado em 12 de julho de 2013)
[3] http://www.amazon.com/The-Art-Application-Performance-Testing/dp/0596520662 (acessado em 12 de julho de
2013)
[4] http://br.groups.yahoo.com/group/DFTestes/
[5] http://jmeter.apache.org/download_jmeter.cgi
[7] http://www.oracle.com/technetwork/pt/java/javase/downloads/index.html
[8] http://www.softwaretestinghelp.com/performance-testing-tools-load-testing-tools/
[9] http://newrelic.com/
[10] http://jmeter-plugins.org/wiki/PerfMonAgent/?utm_source=jpgc&utm_medium=link&utm_campaign=PerfMonAgent

[11] http://wiki.apache.org/jmeter/
[12] http://en.wikipedia.org/wiki/Jakarta_Project
[13] https://github.com/camiloribeiro/rake-jmeter

Destilando JMeter II: Vamos escrever testes!

Dont be evil! Use o JMeter para o bem :]

Esse o segundo post da srie Destilando JMeter. Esse artigo foca nas principais dvidas do dia a dia para quem
est testando pginas. Servios seguem outra linha em muitos casos, e ser abordado em um futuro post.
Para esse post estou tentando algo novo, com a ideia de tornar o post mais iterativo e a ferramenta mais fcil de
aprender (e de quebra de pegar uns exemplos prontos, claro). Caso queira ter 100% de proveito, baixe o arquivo:
JMeterExample.jmx compatvel com JMeter 1,9+ (recomendo o 2.11) e o JMeter para acompanhar os exemplos. Caso
queira um JMeter com todos os plugins, baixe esse https://github.com/camiloribeiro/rake-jmeter/tree/master/jmeter
Eu criei um plano de teste de performance onde vamos habilitando cada um dos exemplos e ver eles funcionando.
Assim voc pode ler o exemplo, entender o conceito e experimentar na ferramenta, apenas habilitando e
acompanhando no relatrio e nos debugers espalhados pelo plano.
O objetivo dessa srie fomentar material prtico, didtico e completamente gratuito em portugus. Ajude-me a
entender o que falta (comente, envie suas dvidas e o seu feedback!), e juntos podemos construir um material que vai
ajudar os novos QAs e developers a ter uma curva de aprendizado mais rpida e fcil em JMeter e teste de
performance.
JMeter sem mouse

Embora o JMeter exija muito mais ateno e cuidado do que velocidade e produtividade, aprender os comandos de
teclado podem (e vo) salvar muito o seu tempo quando estiver debugando. Para demonstrar isso, experimente o
seguinte exemplo: Abra o menu File, clique no Save para salvar as novas mudanas. Agora clique no menu Run e
clique no Clear All para limpar os relatrios. E agora clique novamente no menu Run e clique em Start. Todos esses
cliques podem ser substitudos por Ctrl + SER (Save, Clear e Run).
Outros comandos interessantes: Enable/Disable: Muitas vezes voc vai precisar testar o seu script sem um
determinado elemento, grupo, condio etc. Para fazer isso de forma rpida, use Ctrl + T, tanto para habilitar, quanto
para desabilitar. Stop Testing: Comeou o teste sem querer ou j viu a quantidade de erros no listener e desconfia
que tem algo errado? Pare o teste com Ctrl + .. Duplicate Node: Precisa duplicar um elemento para testar alguma
mudana sem perder o que j estava usando? Ctrl+Shift+C. (Ateno: Use git, mesmo que localmente. J perdi meu
jmx por corrupo de dados algumas vezes. Se no fosse o git teria algumas horas de trabalho )
Quer mais shortcuts? -:> https://wiki.apache.org/jmeter/JMeterShortcuts
Aonde colocar os nodes?

Um node qualquer elemento do JMeter. Como vimos no post Destilando JMeter I: Introduo e Conceitos, eles
podem ser um thread group, um sampler, um listener, um timer, um config element entre outros. S para relembrar, o
funcionamento do node est diretamente relacionado com aonde ele est aninhado. Se um timer por exemplo, est

aninhado em um sampler ( filho de um sampler), ele s vai ser ativado naquele sampler. Lembre-se que apesar
disso, como ele executa uma pausa no teste, ele tem efeitos colaterais sobre o teste como um todo.
Criar um plano

No confunda o plano de testes do JMeter, com algum documento que sua empresa ou cliente precisa ou com o
planejamento/estratgia de testes de performance/carga/stress. Aqui vamos falar sobre o plano da ferramenta e como
flexibiliz-lo para alcanar alguns dos objetivos de um planejamento. Caso tenha interesse sobre planejamento, pode
conferir o nosso post sobre 12 Lies aprendidas em Testes de Performance Server Side ou lendo algum livro sobre
o planejamento. Nesse post vamos trabalhar somente os aspectos tcnicos da ferramenta.
-Plano baseado em iteraes

O plano em iteraes ideal para dois casos distintos. O primeiro e mais comum, o caso de quem precisa testar
uma quantidade limitada de requisies, no importa o tempo. Para ver esse exemplo funcionando, habilite o plano
Fixed number of requests example e execute o teste observando o resultado.

Exemplo
de plano de teste com nmero fixo de execues e threads

O nmero de requests vai ser o nmero de iteraes definido no campo Loop vezes o nmero de threads. O rampup s vai amortecer o incio dos testes, mas no afeta o resultado final em nmero de requests. PS: No se
preocupe, estamos usando um Dummy Sampler, o que significa que estamos emulando requisies dentro do
prprio JMeter.
O segundo modelo o teste eterno. A configurao a mesma, mas ao invs de informar o nmero de repeties.
s informamos o nmero de threads e selecionamos a opo Forever. Esse teste pouco falado. Eu uso ele por
exemplo, para testar a estratgia de rolling-deployment, Blue-Green deploy e eventualmente loging, mas isso um
tpico a ser discutido em um futuro post Caso queira manter um teste de maturidade ou soak test por um perodo
bem long, tambm pode selecionar essa opo.
-Plano baseado em tempo

Esse o meu preferido por alguns motivos. O primeiro e mais obvio, voc tem um timebox, ou seja, acontea o que
acontecer, o seu teste vai levar X minutos/horas. Assim voc pode se programar. Outro fator interessante a
possibilidade de brincar com planos grficos como exemplificado nas figuras do post anterior Destilando JMeter I:
Introduo e Conceitos.
Para o prximo exerccio, vamos voltar a desabilitar (ctrl + T) o plano Fixed number of requests example e vamos
habilitar o plano Load test schedule example. Como j falamos desse plano, vamos brincar com outra coisa. Ignore
o contedo por agora, vamos ver throughput controller mais a frente, tambm tem dummies dentro desse plano.
Observe que no topo do plano, temos algumas opes:

Exemplo
de plano com timebox definida

Salve, limpe os relatrios e execute o teste observando as threads no topo a esquerda (nessa imagem e no JMeter),
onde tem um 10/10 seguido de um quadrado verde na imagem anterior. Observe com ateno. Voc vai ver que as
threads vo crescer de forma linear, se manter estveis e desligar de uma forma linear (2/sec). Isso acontece porque
o nosso plano diz que esperado (ou mais provavelmente aceitvel) ter erros nas respostas desse teste. Logo, caso
ele encontre um erro, ele deve registrar esse erro caso existam listeners, e continuar o teste como se nada tivesse
acontecido. Agora mude para cada uma das opes e observe os comportamentos diferentes.
Cada opo deve ser usada em um contexto. A opo Start Next Thread Loop por exemplo, deve ser usada para
quem tem uma pitada de teste funcional, ou seja, dependncia de resultados anteriores para os prximos
elementos. Vamos ver mais a frente o caso do CSRF Token ou Authentication Token, onde vamos fazer um get para
pegar o token e vamos usar o token para postar algum contedo.
Nesse exemplo, caso falhemos ao fazer o get, no queremos executar um post e aumentar o ruido do nosso teste em
relao a falhas da aplicao. Ao invs disso, podemos ignorar a continuidade desse teste dessa thread, e voltar essa
thread para o incio da requisio, dessa forma ela pode tentar pegar o token de novo com o get e continuar o teste.
Pare alguns minutos e mude algumas configuraes agora. Se precisar depois, pode baixar o arquivo novamente. O
importante agora experimentar, olhando, principalmente, o thread counter no topo a direita e os relatrios
Once Only Controller

O Once Only Controller, no portugus Controlador para Unica Vez um Controlador. Ele controla o fluxo de
execuo do teste, evitando que uma thread execute mais que uma vez um determinado request, ou grupo de
requests. Mas aqui mora um perigo. Ele faz com que cada thread execute esse grupo uma vez, e no que o teste
execute esse grupo uma unica vez. Para entender, Vamos experimentar um de cada vez e ver o resultado no relatrio
de Summary Report.

Once
Only Controler X Throughput Controller

Novamente, no se preocupe com os requests. Habilite somente o primeiro exemplo Example of Once Only
Controller e execute o nosso mantra (ctrl + SER). Observe o Summary Report. No final do teste, voc vai notar que
cada uma das dez threads do nosso teste, passou nesse request uma vez. Essa abordagem interessante para
casos onde temos que buscar algum valor em uma pgina para todos os testes subsequentes, e que esse valor no
mude conforme novas execues forem realizadas.
Agora, desabilite esse teste e habilite o Thoughput Controller with unmarked per user. Execute ctrl + SER e veja o
novo resultado. No final do teste, vai observar, que no importa o nmero de threads, o teste sempre vai executar
essa operao, ou esse grupo de operaes, uma nica vez. Essa abordagem pode ser usada quando temos que
injetar dados por exemplo.
Ps: Mais a frente vamos observar que podemos usar mais de um thread group ao mesmo tempo, e que claro,
podemos ter um thread group com uma thread responsvel por realizar setup dos dados tambm. O objetivo aqui no
dar uma soluo, mas ajudar iniciantes e intermedirios a experimentar diferentes abordagens e componentes do
JMeter.
PS: Caso esteja usando mais de um JMeter agente/slave (cluster) para executar testes de dois ou mais
computadores, o exemplo Example of Real Once Only Controller vai executar um request para cada uma das
mquinas. Ento cuidado com inseres de dados. sempre mais recomendvel fazer esse tipo de operao com
ferramentas prprias para isso, como Chef ou Puppet.
Trabalhar com Headers e meta informaes

O protocolo que usamos para web bem simples. Ele composto por um HEADER (cabealho) e um BODY (corpo)
em abos os sentidos. O Header possui meta informaes sobre a requisio e sobre a resposta, enquanto o corpo
possui o contedo trafegado.
O header muito importante. Atravs dele definimos muitas informaes importantes, como por exemplo o tipo de
contedo do body (HTML, JSON, XML, etc). O HTTP um protocolo sem estado, ou seja, cada requisio nica e
no contem por exemplo uma sesso para manter o usurio ou os privilgios, por isso usamos tambm o HEADER
para enviar informaes de autenticao.

Exemplo
de headers manager

Trabalhar com o JMeter envolve conhecer muito de HTTP, por isso, caso no conhea os tipos de header, procure um
livro ou material na internet mais aprofundados. Nesse tutorial vamos focar na ferramenta, mas eu recomendo uma
leitura desse artigo (https://en.wikipedia.org/wiki/List_of_HTTP_header_fields) antes de continuar nessa sesso, j
que vamos ver alguns exemplos bem simples. Vamos ver mais exemplos usando header mais a frente
Extraindo AuthTokens para variveis

Authentication Tokens foram um mecanismo criado com dois objetivos. O primeiro e mais comum, garantir que o
usurio o usurrio, em caso de redes sociais e aplicativos que requerem logins. O segundo motivo para evitar que
maquinas de repetio (como o JMeter ou Selenium por exemplo), webspiders (modelo de ferramenta para procurar
vulnerabilidade), crawlers (ferramentas para baixar contedo de forma automtica) consigam navegar pelo site.
Claro que o mecanismo falho, e o auth token no a soluo definitiva (e nem nica!) para resolver esse problema.
O Authentication Token uma dificuldade a mais quando falamos de automatizar testes de performance. Eu j usei
ferramentas que lidavam razoavelmente com isso, como o Visual Studio 2010, o Rational Performance Tester e o
prprio JMeter, mas em nenhuma delas, e em nenhum dos casos, isso foi gerenciado pelo record and replay da
ferramenta.
Isso acontece porque diferentes sistemas implementam a segurana e a autenticao de maneiras diferentes. Alguns
enviam um token novo para cada post. Outros pedem valor criptografado com o payload em duas ou trs camadas de
criptografia. Ou seja, no existe uma maneira simples e definitiva de lida com isso. O que voc deve fazer conversar
com o seu time e descobrir como funciona a autenticao do seu sistema.
Aqui vamos executar dois exemplos, o CSRF e o de criptografia (mais a frente). O primeiro nessa sesso, vamos
simular o modelo usado pelo Rails, chamado de csrf token (usado para evitar o ataque conhecido como Cross-Site
Request Forgery).
Para fazer isso usando o Regular expression extractor por exemplo, comente todos os demais nodes e ative o
Extracting and sending Authentication Token. Observe que ele tem dois samplers, um Get e um Post (ambos dumy
teste). Agora olhe o contedo do response data do primeiro request (get) conforme a imagem abaixo:

Exemplo
de token dentro do HTML de uma pgina

A imagem acima simula um request com o body contendo um token. Eu copiei esse snippet do meu Facebook
autenticado, ento um exemplo relativamente real. Se observar agora, aninhado nesse request, existe um Regular
expression extractor, onde definimos uma expresso regular para pegar esse valor (veja a figura abaixo):

Extrao
de token de dentro de um corpo do html

No nmero 1 definimos de onde queremos pegar o HTML. Isso importante porque em alguns casos temos subsamples por conta de redirecionamentos por exemplo (Falaremos sobre isso mais tarde). O nmero 2 define de
aonde vamos executar a expresso regular. Nesse caso, queremos pegar um token no corpo, mas em outros casos,
podemos querer pegar uma URL no header, mais especificamente no header location. O nmero 3 a definio do
nome da varivel onde vamos guardar esse valor. E por ultimo, temos a expresso regular e o template. Caso tenha
mais
interesse
em
expresses
regulares
leia
https://developer.mozilla.org/enUS/docs/Web/JavaScript/Guide/Regular_Expressions. Aqui vamos nos limitar ao bsico, usando uma expresso
regular no muito bonita, mas de fcil compreenso, focando no uso do JMeter e deixando essas especificidades
tcnicas de lado.
Feito, isso, o nosso segundo request, que o nosso post, vai usar o HTTP Header Manager comentado
anteriormente para enviar o Authorization Header. Um terceiro elemento (Debug Sampler) ainda no comentado, mas
que vai ser abordado mais a frente est ali para nos ajudar a ver o contedo da varivel. Se voc executar o teste
agora, e olhar no relatrio View Results in a Tree qualquer um dos itens para Debug Sampler, vai ver que o valor
da varivel authToken que definimos realmente o valor do token que extramos (Pode ver isso tambm no body do
nosso post request):

Resultad
o do Debug mostrando valor da varivel no relatrio

Lembre-se que esse um exemplo bsico, mas voc pode usar essa estratgia para quase qualquer website usando
os frameworks mais populares, como Rails pra Ruby, Django pra Python ou Dropwizard/Jersey pra Java. Entenda o
mecanismo do seu framework ou time e drible ele nos seus testes de performance.
- Outros usos para variveis

Variveis podem ser usadas por uma infinidade de razes. Enviar um Header ou authentication token dinamicamente
um exemplo interessante, mas tambm podemos usar variveis para guardar uma URL criada pelo teste (exemplo
citado do Location header) entre outras. Use a criatividade e pense em como reusar as informaes que a prpria
pgina te d.
Criar assersses
-Validando 404 e outros erros

Algumas vezes voc vai querer validar erros. Sim! Testar no s testar o que funciona, mas testar se os erros
esperados se comportam como deveriam, inclusive que isso no impacta a performance.
Mas existe um problema muito srio. O JMeter, por padro segue a conveno de que cdigos 1XX so
informacionais, 2XX sucesso, 3XX Redirecionamento, logo respondem como sucesso, enquanto 4XX so erros do
cliente e 5XX erros do servidor. Nesse caso, ele levanta um erro automaticamente sempre que um request 401
respondido pelo servidor. Para evitar isso devemos especificar explicitamente que esperamos aquele response code.
O jeito mais fcil de fazer isso usando uma assero de resposta (Response Assertion).
V ate o nosso projeto e comente todos os testes, e deixe somente o teste Validating 401, 404 and other errors
habilitado. Voc vai observar que dentro dele, existe um outro elemento desabilitado que se chama Expected 401
With error, deixe-o desabilitado. O exemplo deve parecer com essa figura:

Exemplo
de explicita assero de cdigo de erro experado

Agora execute o teste. Voc vai ver que o nosso teste est verde, mesmo recebendo um 404. Isso aconteceu pela
combinao de dois fatores:
1 Nos definimos nesse assert que no nos importamos com o cdigo retornado, marcado re roxo no canto direito da
imagem. MUITO cuidado com isso. Se marcar essa opo, o JMeter no vai logar NENHUM cdigo de erro desse
request como erro. Cuidado com o falso positivo. Para ver isso quebrando, desmarque a opo e rode o teste de
novo. Vai ver que mesmo passando na condio testada, o status ainda quebra o teste.
2 O nosso teste est esperando um Response Code equals to 404 e recebeu um 404. Sempre que usar a opo
citada anteriormente, de ignorar status, tenha certeza absoluta que est cobrindo as condies do teste. Para ter
certeza voc pode usar o debug sampler (vamos ver a frente), pode usar um Dummy teste retornando o que est
esperando (como nesse exemplo) ou pode ainda ter mais de um assert, assim, alm de validar o cdigo do erro por
exemplo, pode validar o o corpo ou algum header (Content-Type: error por exemplo).
Agora desabilite somente esse node Expected 404 e habilite o Expected 401 With error. Execute e ver o erro
que pegamos quando o status est ignorado, mas a condio no foi satisfeita, como mostrado na imagem abaixo:

Exemplo
de erro em um assert de cdigo de erro do JMeter

Esse erro bem parecido com o do JUnit ou Cucumber por exemplo. Pratique um pouco mais usando o Dummy
teste. Mude o Dummy test para ter outros valores. Crie duas ou trs asseres e veja como isso funcione. Explore e
aprenda mais!
Settando variveis e escrevendo java

O JMeter tambm permite que adicionemos novas variveis a qualquer momento, bem como mudar o valor delas. No
exemplo abaixo, vamos ver como fazer isso usando vars.put e tambm vamos executar um snippet de cdigo em
java. Essa uma das vantgens do JMeter 2.11, j que ele permite ter melhor legibilidade do que as verses
anteriores. Para acompanhar o exemplo, desabilite todos os demais testes e habilite somente o teste Example using
bean shell processor. Observe que estamos usando dois componentes novos. Um User defined variables, onde
podemos definir variveis e valores padro para elas, e um segundo elemento chamado Bean Shell Pre Processor.
O pr processor faz exatamente o contrrio do ps processor. Ele executa antes de enviar o request, e nele podemos
fazer vrias coisas, como mudar valores de variveis, executar comandos java, ler um banco de dados, etc. O
exemplo abaixo mostra uma pequena rotina em java, importando e duas classes e executando uma operao para
criptografar uma String antes de envi-la no request:

Exemplo
de bean shell preprocessor com snippet de cdigo java

No exempo acima, depois de executar o cdigo java, usamos o vars.put(nomeDaVariavel, valorDaVariavel) para
incluir o valor desejado. Lembre-se que se usar o pre-processor para isso, o valor vai ser setado antes de fazer o
request em que ele est aninhado, caso use o pos-processor o valor ser setado depois do request. Experimente
mudar algumas coisas na operao. Tente incluir essa varivel em um header de authentication por exemplo. Depois
use alguma operao java para receber um valor e descriptograf-lo
BONUS! Postando vrios dados diferentes de um arquivo CSV

Foi pedido por email para implementar tambm o post de valores vindos de um arquivo CSV. Aqui vai um exemplo
bem simples de como fazer isso. Desabilite todos os outros nodes e habilite o node Geting data from a CSV file.
Observe que temos um arquivo com trs colunas na raiz do nosso projeto no github. Nesse arquivo podemos ter

qualquer tipo de informao, como por exemplo os dados para cadastrar usurios, dados para injetar em um JSON ou
mesmo para passar em uma querystring.
No JMeter temos que adicionar um CSV Data Set Config, e especificar os nomes das variveis que vamos usar,
como nos exemplo abaixo:

Adicionando um config file

para buscar informaes em um arquivo CSV

Com essa configurao, falamos para o jmeter para buscar esse arquivo representado pelo filename, setar as
variaveis para cada uma das colunas (sem cabealho no arquivo!) e finalmente temos as opes de encerrar o teste
no final do arquivo ou continuar voltando ao comeo. No meu caso de exemplo, eu pedi que ele reciclar o arquivo,
mas voc pode mudar e ver como o teste acaba quando chegamos ao final do arquivo.
Para usar os valores basta inclulos basta usar o nosso padro ${variavel} visto anteriormente:

Exemplo de envio
e recebibento de variaveis do arquivo csv

O resultado como esperado pode ser visto usando os dummy tests que estamos usando desde o comeo do tutorial:

Visualizao

dos

dados vindos do arquivo csv depois da execuo

Crie mais dados, experimente combinaes diferentes. Tente usar outros config elements para buscar informaes
em bancos de dados tambm.

BONUS 2! Postando valores randmicos

O JMeter tem um conjunto gigante de funes prrias. Voc pode ler e aprender mais sobre elas na definio da API
do jmeter https://jmeter.apache.org/usermanual/functions.html. Caso seja necessrio por exemplo, mudar algum
valor no final de uma varivel para que ele seja nico voc tem duas opes.
Usar a funo ${__Random()}, ${__RandomString()} ou uma combinao delas com a ${__Random()}. Para testar
isso, desabilite todos os outros testes e deixe somente o teste Posting a unique string with random function. Vai
ver que as funes esto definidas de acordo com a imagem abaixo:

Trs
exemplos de funes randomicas para seus testes

O resultado pode ser bem interessante, dependendo de qual charset voc quer usar. No nosso caso no temos
preferncia por charset algum, ento temos letras de vrias lnguas:

Resultad
o das funes randmicas

Experimente mudar as combinaes, passar essas funes nos headers, final de urls, em cookies e aproveite para
usar esses testes para definir testes de charsets tambm. Para mais consulte a documentao da Random
(https://jmeter.apache.org/usermanual/functions.html#__Random),
RandomString
(https://jmeter.apache.org/usermanual/functions.html#__RandomString)
e
dateTime
(https://jmeter.apache.org/usermanual/functions.html#__time)
O que achou desse novo post sobre JMeter? Espero que tenha gostado. compartilhe e vamos para o prximo level.
Envie suas dvidas aqui no comentrio. Infelizmente no consigo responder todos os meus emails e acabo deixando
alguns sem responder. Se estiver aqui no blog, algum que tambm tenha trabalhado com JMeter pode ver e
responder mais rpido.

Sinta-se a vontade para levar o material para sua empresa e us-lo (inteiro ou parcial) em treinamentos ou quaisquer
atividades no comerciais. Todo esse material desenvolvido de forma voluntria. Voc me ajude a continuar
postando quando compartilha esse e outros posts no LinkedIn ou Twitter, ou mesmo mandando um e-mail para a lista
de teste/desenvolvimento da sua empresa.