Destilando JMeter I - Introdução e Conceitos - The Bug Bang Theory
Destilando JMeter I - Introdução e Conceitos - The Bug Bang Theory
Destilando JMeter I - Introdução e Conceitos - The Bug Bang Theory
A 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 su ciente 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
lingua 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 gr ca e vamos preparar o JMeter com os plugins e
ferramentas mnimas para executarmos load tests, stress tests e soak tests com
pro ssionalismo. Ainda vamos ter uma viso geral dos relatrios, con guraes 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 gr co de Tempo de Resposta por Tempo do JMeter [13]
e faz um adendo:
Teste onde submetemos aplicaes a cargas e condies espec cas por tempo
determinado a m de observar e avaliar os diferentes comportamentos que
essas condies e cargas vo proporcionar.
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 classi cados em dois grupos:
Disponibilidade
Tempo de resposta:
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 exempli car o throughput de uma pgina como a quantidade de vezes
que conseguimos receber uma resposta completa dessa pgina por segundo.
Esse nmero importante porque de ne a capacidade da aplicao. Quando
falamos em usurios, devemos fazer estudos entender o quanto esses usurios
esto acessando essa aplicao ou pgina, para ento de nir 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
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)
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*.
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.
* 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.
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 identi car falhas que no eram pegas antes,
como por exemplo um memory leak resultante de uma garbage collector mau
con gurada 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, que a vontade
para mudar a nomenclatura na sua empresa.
Cenrios
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
Google Analytics como ferramenta para de nir situaes semelhantes as reais, para
cenrios e distribuio de carga
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.
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 con gurados,
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.
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, identi cando por exemplo quando o load
balancer no estiver calibrado.
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
espec cos para essas situaes e evitar problemas mais graves em produo.
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 o cial 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.
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/
$./jmeter
Turbinando o JMeter
Agora voc deve ver a interface gr ca 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.
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 De ned Variables. Dentro desse elemento
podemos armazenar um grande nmero de variveis que podem ser usadas
livremente em todo o script para exibilizar 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.
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 nalmente desligar uma thread por segundo (Startup time igual ao
nmero de threads). O Ultimate Thread Group disponibiliza uma viso gr ca do
nmero de threads, que inclusive inspirou o meu gr co que exempli ca 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 con gurao Action to be taken after a sampler
error.
Logic Controllers
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 uxo 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.
** Teste realizado com vrias pginas ou apis ao mesmo tempo, para de nir 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 timeronde informamos uma variao entre X e Y para a nossa
pausa, alm de outros timers.
Samplers
* Uma pgina pode consumir dezenas de servios, incluir outras pginas, assets,
consultas sql, etc., logo essa a rmao diz respeito a um request para algum
elemento, desconsiderando o seu comportamento interno que pode fazer novas
chamadas.
Name: Um nome descritivo e intuitivo sobre a pgina ou servio sob teste deste
sampler.
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 car 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
Ribeirohttp://www.google.com.br/#q=camilo+ribeiro
Preprocessors e Postprocessors
Asserssions
Assim como testes funcionais, podemos usar mecanismos de veri cao para ter
certeza que o nosso teste est funcionando corretamente. Essas veri caes
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 veri caes que tem o poder de mudar o resultado de um
script avisando ao JMeter que est tudo bem (ou no). Os principais modelos de
veri caes que temos so:
Duration Assertion: Voc vai ter um relatrio no nal, mas se quiser falhar um
request por ultrapassar um determinado tempo de resposta voc pode usar uma
veri cao de quanto tempo ele est levando para terminar de carregar.
Response Assertion: Voc pode de nir 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 veri cao dele, ele no desempenha esse papel da melhor forma. Use essa
ferramenta para testes de carga como estamos descrevendo aqui.
Listeners
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
Listener View Results in a Tree (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.
Eu gosto muito de usar esse relatrio como uma primeira viso do resultado. Caso
identi que 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
O relatrio de tempo de
resposta por tempo de
execuo pode te mostrar
dados interessantes sobre o
comportamento diversi cado
das suas pginas/servios
durante o tempo de uma forma
gr ca. Ele tambm tem a Response Time over Time
capacidade de te mostrar de
uma maneira bem simples se
voc teve um outlier (valor atpico) tanto para cima quanto para baixo.
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.
Em testes de estresse por exemplo, onde uma abordagem pode ser aumentar a
carga inde nidamente 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
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.
$ wgethttp://jmeter-plugins.org/downloads/ le/ServerAgent-2.2.1.zip
$ tar -zxvfServerAgent-2.2.1.zip
$./startAgent.sh
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
de nitiva, voc pense sobre o que quer medir e ento estabelea um conjunto de
mtricas.
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.
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.
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 identi cado
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.
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
Resposta 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 con guraes 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 cando 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
Referencias
[1]http://en.wikipedia.org/wiki/Software_performance_testing (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
About LatestPosts
Camilo Ribeiro
Test Engineer at Klarna