Palestrante: Evandro Grezeli de Barros Neves - CIELO Jmeter é uma ferramenta livre e open source cujo objetivo é gerar carga para estimular plataformas online, independente do tipo de arquitetura. Dando continuidade a trilha sobre testes de desempenho, neste workshop será apresentado como é o funcionamento desta ferramenta e qual a melhor forma de utiliza-la, citando exemplos de utilização em uma arquitetura remota com agentes escravos; melhores práticas para não onerar a ferramenta; exemplos de scripts para testes baseados em filas MQ, frameworks com visão e simular navegação de usuários.

1. M
Evandro Grezeli
egrezeli@gmail.com
Maio/2016
Abrindo a Caixa de
Ferramentas
Atirando Pedras com Jmeter
Maio de 2016

2. Sobre
Entusiasta em assuntos que tangem a desempenho
de aplicação
+10 anos de experiência com desenvolvimento de software Java e
otimização de sistemas em baixa plataforma
Manutenção e desenvolvimento de componentes para o Jmeter
Colunista no site http://jmeter.com.br
Especialista em capacidade e desempenho na maior companhia de
meios de pagamento do Brasil

3. ANTERIORMENTE
NO CMG 2015...

4. Em 2015...
Falando de testes de desempenho
Importância de testes de desempenho
O conceito do tempo de resposta
Reconhecimento do Ambiente
Tipos de testes de desempenho
Metodologia e Planejamento

5. Agenda
Configurando o ambiente
Modos de usar o Jmeter
Melhores práticas para criar, testar e atirar
Casos complexos e saídas (MQ e Framework
com visão)

6. Configurando o ambiente

7. Configurando o ambiente
Pré requisitos mínimos*:
* fonte oficial: http://jmeter.apache.org/usermanual/get-started.html
OK, e...?
… se eu quiser simular 1.000 usuários virtuais?
… utilizar recursos visuais durante o teste?
… trafegar todos os elementos da página?
… utilizar beanshell durante o teste?
… realizar validações em todos os passos do teste?

8. Configurando o ambiente
Jmeter é uma ferramenta que precisa de uma caixa dentro de uma caixa
SO 2.5 GB
Jmeter JVM
1.5 GB
Ligado diretamente com a capacidade de memória (alocação de thread)
E CPU (velocidade que as threads trabalham)
Exemplo
Intel Core i7 @ 2.20GHz
4 GB RAM DDR3
100 GB disco
Cenário simples
expressões regulares; output em arquivo;
distribuição de peso nativa
Na prática, a conta* é
para cada thread criada no Jmeter, é
necessário 2,5 MB disponível na JVM
* pode variar de acordo com a forma que o Jmeter é inicializado, para mais!

9. Modos de usar o JMeter
GUI (para testes e criação)
Linha de comando (apenas para teste)
Onde:
-n: indica que não deve ser aberta a GUI
-t: o caminho do script que será executado
-l: arquivo gerado com informações do teste
DICA
Interrompa os testes no
modo
non-gui utilizando os scripts
stoptest.sh ou stoptest.cmd

10. Modos de usar o JMeter
Mestre e Escravo
Certifique-se que:
Mesma versão de Jmeter
Mesma versão de JVM
Massa de dados estão no local correto
Iniciando o(s) escravo(s)
Adicione o endereço do escravo no mestre
No arquivo jmeter.properties

11. Modos de usar o JMeter
Mestre e Escravo
Certifique-se que:
Mesma versão de Jmeter
Mesma versão de JVM
Massa de dados estão no local correto
Iniciando o(s) escravo(s) de forma non-GUI
Onde:
-n: indica que não deve ser aberta a GUI
-t: o caminho do script que será executado
-r: endereços dos servidores escravos presentes no properties

12. Melhores práticas
Criar
Basicamente, Jmeter se divide em duas áreas
Testplan: Área destinada a colocar os elementos referentes ao teste
Workbench: Área destinada a colocar os elementos que gravam requisições HTTP
O que deve se atentar:
Para facilitar na criação, na área “TestPlan”, adicione um “Thread Group” e use-o
como “Target Controller”
Agrupe as transações, definindo no combo box “Grouping” a opção “Put each group
in a new transaction controller”
Adicione as exclusões sugeridas, clicando no botão “Add suggested excludes”
View results tree serve
para visualizar a navegação
já realizada

13. Melhores práticas
Testar
User Defined Variables
Sempre tenha váriaveis locais no script, para
dar fácil manutenção no mesmo
Exemplo
Endereço de diretórios para escrita de log, leitura de
massa de dados; diferentes valores de endereços web
(ambiente homologação, TI, produção)
HTTP Cookie Manager
Permita que o Jmeter gerencie os cookies da
aplicação de forma automática
HTTP Header Manager
Toda requisição Web deve ter um cabeçalho,
com este componente o mesmo é
padronizado para todas as requisições

14. Melhores práticas
Testar
CSV Data Set Config
Com este componente é possível utilizar um
arquivo CSV (comma-separated-value)
para massa de dados das requisições
HTTP Request Defaults
Todas as requisições Web possuem um
caminho padronizado
Response Assertion
Verifica na resposta da requisição através
de padrões de buscar por um trecho de
texto específico, URL, código de resposta
HTTP e resposta de um header

15. Melhores práticas
Testar
Throughput Controller
Através deste componente é possível
definir o peso de cada umas das
requisições, em percentual
Regular Expression Extractor
Através de um motor de expressão regular
baseado em Perl, é possível extrair
informações de uma resposta web e
utiliza-la posteriormente

16. Melhores práticas
Testar
View Results Tree
Uma vez criado, editado e configurado o
script, com este relatório é possível
visualizar através de um simulador de
navegador web como foi o request enviado
e qual o seu response
ATENÇÃO
Este componente consome
muita memória da JVM, portanto
não esqueça de desabilita-lo
antes de executar um teste pesado

17. Melhores práticas
Atirar
Ultimate Thread Group
Uma biblioteca construída pela comunidade
que permite o incremento de threads
(ramp-up) ao longo de um
tempo pré-determinado
Exemplo

18. Melhores práticas
Atirar Simple Data Writer
Gerenciador de escrita em disco que não
interage com a interface gráfica (leve)
Exemplo de configuração
DICA
Por padrão, o Jmeter escreve o
timestamp como epoch time, altere para
uma forma mais legível alterando no
jmeter.properties

19. Caso 1: Teste com MQ
Nativamente, o Jmeter tem suporte ao protocolo MQ, no caso JMS
O JMS Point-to-Point envia uma mensagem única e exclusivamente
para uma destinada fila de uma aplicação de maneira assíncrona.
QueueConnection Factory
Nome JNDI (definição de um contexto que específica
aonde procurar um objeto, no nosso caso um objeto no
Websphere MQ) da queue connection factory
(direcionamentos do depósito de informações iniciais
de filas) que será utilizado para conectar com o
sistema de mensagem.
JNDI name Request queue
Nome JNDI da fila já previamente criada
Content
O conteúdo da mensagem que será enviada
Communication Style
Conforme o teste, deve ser escolhido entre request ou request-response

20. Caso 1: Teste com MQ
Initial Context Factory
É a definição para o JNDI aonde ele deve começar a
procura pelo contexto. Para contexto de arquivos de
sistema, preencha este campo com
“com.sun.jndi.fscontext.RefFSContextFactory”.
Provider URL
Ao definir o contexto de busca por arquivos de sistema, neste campo é definido aonde este arquivo se
encontra, neste caso citando que ele deve abrir o arquivo presente na pasta onde o arquivo binding
foi gerado. Este campo deverá ficar preenchido da seguinte maneira: file:${caminho}.
Onde:
file: informo ao JMeter que ele deve abrir o primeiro arquivo que ele encontrar
dentro de um caminho específico
${caminho}: uma variável definida apontando o diretório onde o arquivo se
encontra do gerenciador de fila está gerado, com os apontamentos devidos

21. Caso 1: Teste com MQ
O resultado de um teste para verificação,
deve ser assim:

22. Caso 2: Teste IceFaces e
AjaxPush
Componente de visão é uma forma que o desenvolvedor tem de armazenar
a navegação do usuário entre “push” e “push back”, do lado do cliente ou do
lado do servidor
“The Horror!”
Viewstate windowstate
eventview
Expressões regulares bem aplicadas, conhecimento da aplicação
resolvem os problemas!
AjaxPush

23. Caso 2: Teste IceFaces e
AjaxPush
Jmeter e Javascript/Ajax?
Oficialmente, não é suportado pelo Jmeter requisições
do tipo cliente side. Portanto, para poder atualizar as
requisições de uma post, é necessário extrair dados de
um response.
DICA
O Jmeter respeita hierarquia. Uma vez
colocado expressão regular antes de
requisições, a mesma será aplicada toda
vez que as condições forem atendidas
Exemplo de regex:

24. Caso 2: Teste IceFaces e
AjaxPush
Desafio é conseguir simular de maneira correta o Ajax Push.
A requisição que aguarda pela atualiazação do icepush é um servlet que
bloqueia a requisição quando uma atualização da visão é realizada (tempo
padrão para este mecanismo é de 55 segundos). Se nenhuma atualização
estiver disponível após o tempo aguardado, uma resposta contendo o valor
<noop/> retorna como resposta da requisição.
SOBRE
O Ajax Push permite a aplicação atualizar qualquer parte da página em qualquer
momento para qualquer grupo de usuários, através de requisições assíncronas
disparada pelo cliente ao servidor.

25. Caso 2: Teste IceFaces e
AjaxPush
Para que seja visualizada uma atualização
do pushId, é necessário enviar na
requisição a ice.view daquele instante.
Logo após esta requisição, é feita uma
expressão regular para extrair a resposta
da mesma

26. Caso 2: Teste IceFaces e
AjaxPush
Logo após a extração da resposta da requisição, é feita uma verificação
condicional através do If Controller. Caso a condição seja satisfeita uma
requisição a aplicação é feita com os novos dados atualizados da página
IMPORTANTE
Ao final do ciclo da thread, deve ser enviado um submit
contendo o “dispose” da visão, para não sobrecarregar a
memória do servidor (simular usuário real)

27. Abrindo a Caixa
de Ferramentas
Evandro Grezeli
egrezeli@gmail.com
http://br.linkedin.com/pub/evandro-grezeli/6/b88/719/en

28. Teste de Desempenho:
Para saber mais...
Referência bibliográficas:
Myers, Glenford J. The Art of Software Testing. 2ª ed. New Jersey: John Wiley & Sons
Inc, 2004.
Bartié, Alexandre. Garantia de Qualidade de Software. 3ª ed. São Paulo: Campus, 2002.
Pressman, Roger S. Engenharia de Software. 6ª ed. São Paulo: Pearson Makron Books,
2005.
Menascé, Daniel A., Almeida, Virgilio A. F. Planejamento de Capacidade para serviços
na Web: Métricas, modelos e métodos. São Paulo: Campus Elsevier, 2003.
Miller, Robert B. Response time in man-computer conversational transactions. New
York: International Business Machine Corporation, in press.
Almeida, Virgilio, Menascé, Daniel A., Dowdy, Larry W. Performance by Design:
Computer Capacity Planning by Example. New Jersey: Prentice Hall, 2004.
Meier, J. D. et al. Performance Testing Guidance for Web Applications. Redmond:
Microsoft Press, 2007.

29. Teste de Desempenho:
Para saber mais...
Referência web:
Jmeter BR
http://www.jmeter.com.br
Performance Project Planning
http://www.wilsonmar.com/perfplan.aspx
Memory leaks in enterprise java applications
http://www.javaworld.com/javaworld/jw-03-2006/jw-0313-leak.html
Introducing Microsoft Web Application Stress Tool
http://www1bpt.bridgeport.edu/sed/projects/cs597/Fall_2002/jishah/web_application_stress.htm
Load testing web applications using microsoft web application stress tool
http://www.west-wind.com/presentations/webstress/webstress.htm
FAQ – Performance & Load Testing
http://www.sqaforums.com/showflat.php?Cat=0&Number=41861&an=0&page=0
User Experience, not metrics
http://www.ibm.com/developerworks/rational/library/4228.html
Top 25+ Reasons Web Applications don’t scale
http://whitepapers.techrepublic.com.com/abstract.aspx?docid=38871