Vou falar agora um pouco sobre o jmeter, uma ferramenta do grupo apache, para a realização de testes de performance, carga e stress. Apesar de ser este o foco do jmeter (testes de performance, carga e stress) ele também pode ser utilizado para realizar testes em webservices, banco de dados e também automatizar alguns teste funcionais, seu uso, alias, é bastante amplo. Lógico que existem ferramentas que desempenham o mesmo papel que o Jmeter como o caso WAST (Web Application Stress Test), WebLoad mas vamos aborar jmeter neste momento.

Irei mostar a seguir, o Jmeter em sua operação mais básica e nos posts decorrentes irei aprofundando na sua aplicação.

Quem vê o Jmeter pela primeira vez não deve se sentir muito confortável devido a sua relativa falta de intuitividade, mas isso logo passa depois que você entende sua estrutura, que pelo que vocês irão ver, é bem simples.

Creio que a melhor forma de entender a estrutura de elementos da árvore do Jmeter é mostrando logo de início um script do Jmeter todo pronto, pois assim fica mais prático. Irei portanto, usar como exemplo um script que escrevi para alguns testes de performance e stress, são scripts simples que mostram como é fácil usar esta ferramenta.

Antes, irei mostrar onde se encontram os elementos que serão utilizados no exemplo que irei dar, veja na imagem abaixo como chegar neles.

Bem agora vamos para o script com os elementos que utilizei.

Vamos lá, na ordem:

1. Inserindo História – Thread Group (Add > New > Thread Group)

Este é o começo de qualquer script (ou plano de teste, se preferir) no jmeter, este elemento inicia seu script, todos os outros elementos que serão interpretados pelo jmeter devem ficar obrigatoriamente abaixo deste thread group, você pode, se preferir, organizar seu script em vários thread groups sem problemas. É aqui no Thread Group que você irá indicar número de conexões simultâneas, Ramp-up e Tempo de Execução.

2. HTTP Request Defaults (Thread Group > Add > Config Element > HTTP Request Defaults)

Aqui você define o padrão de seus requests HTTP, este elemento basicamente gerência os HTTP requests que essa thread está prestes a fazer.

O que basicamente deve estar preenchido neste elemento é o campo Server Name or IP.

3. HTTP Cookie Manager (Thread Group > Add > Config Element > HTTP Cookie Manager)

Suporte a Cookies, você pode remover este elemento, mas recomendo deixar. Este elemento garante que cada Thread vai receber seu próprio cookie.

4. CSV Data Set Config (Thread Group > Add > Config Element > CSV Data Set Config)

Esta aqui é uma facilidade do jmeter, em telas de login ou qualquer tela que você tenha que passar dados para o browser, você pode usar este elemento, ele funciona da seguinte forma.

Você preenche arquivo .csv com os parâmetros que você vai querer passar, conforme imagem abaixo

Salve e depois volte ao elemento CSV Data Set Config e informe respectivamente nome para os valores acima admin e 1234, conforme imagem abaixo

Neste momento, ao rodar o script o jmeter vai vincular USER=admin e PASS=1234, e você pode chamar estes valores em qualquer lugar do script assim: ${USER} e ${PASS}.

No caso deste script irei utilizar estes valores no campo abaixo.

5. /redes2/login.do

Aqui é onde começa a interação com o browser, ou seja, onde as requisições são efetivamente realizadas, existe uma forma bem fácil de conseguir estas informações, usando uma funcionalidade chamada HTTP Proxy Server.

Com o HTTP Proxy Server você pode gravar ações no browser e o jmeter irá gravando tudo pra você, basta que você informe nas configurações de seu browser a porta 8080 (você pode alterar para qualquer porta disponível no seu pc) e pressionar PLAY

Pronto, feito isso, o jmeter deverá lhe poupar de realizar manualmente estes passos.

Como mencionado no tópico 5) irei usar os valores ${USER} e ${PASS} aqui.

6. Browser-derived headers

Estes controles o HTTP Proxy Server adiciona automaticamente, não se preocupe com eles.

7. /redes2/viewHome.do

Mais um request gravado pelo HTTP Proxy Server

8. Browser-derived headers

Estes controles o HTTP Proxy Server adiciona automaticamente, não se preocupe com eles.

9. /iredes2/confirmCreateNarrative.do

Mais um request gravado pelo HTTP Proxy Server

10. Browser-derived headers

Estes controles o HTTP Proxy Server adiciona automaticamente, não se preocupe com eles.

11. Counter – (Thread Group > Add > Pre Processors > Counter)

Esta aqui é outra facilidade do jmeter, quando existe a necessidade de se incluir vários registros sequencialmente no banco, a melhor forma de se fazer isso é via estes Counters, ele vai basicamente incrementar em +1 (isto no entanto é configurável)

No caso acima ele vai começar com 1 incrementar de 1 em 1 até 100 e o nome de referência é H, ou seja, onde você quiser utilizar este counter, basta chamar ${H} onde queres incrementar, veja imagem abaixo.

12. View Results in Table – (Thread Group > Add > Listener > View Results in Table)

Bem aqui é a parte dos relatórios, este relatório exibirá os seguintes valores

13. View Results Tree – (Thread Group > Add > Listener > View Results Tree)

Os resultados estão vazios, mas ele lista aqui todos os requests e alem disso aqui você tambem pode renderizar o HTML e ver exatamente o que este request fez, ótimo para debugar caso ocorra algum problema.

14. Graph Results – (Thread Group > Add > Listener > Graph Results)

15. Save Responses to a file – (Thread Group > Add > Post Processors > Save Resonses to a file)

Salva requisições em um arquivo

16. Generate Summary Results – (Thread Group > Add > Post Processors > Generate Summary Results)

Salva um sumário em um arquivo

Você pode organizar tudo em várias threads desta forma

E antes de finalizar esta parte que é a mais importante

Estas são as propriedade de uma Thread, você deve informar nela o que você vai fazer

Number of Threads – Quantidade de Threads que será realizada

Ram-UP – Tempo que o jmeter para executar as threads informada acima

Loop - Quantas vezes ele irá realizar esta atividade

No caso acima 10 requisições em 60 segundos repetindo 5 vezes

No final consolido estes resultados em uma planilha

Update 08/09/2011

Download do arquivo .xls com o gráfico acima.

comentários

leia mais...

• Dicas JMeter: ‘Once Only Controller’
• Questionamentos sobre o Testlink (#1)
• Ferramentas de Teste: JMeter (2)
• Testes Unitários com csUnit
• Cobertura de Código com NCover

Copyright © 2007-2008 zezologs.org | Todos os direitos reservados | Acessibidade | WordPress ]]> http://www.zezologs.org/blog/ferramenta-de-testes-jmeter/feed/ 19 http://www.zezologs.org/blog/server-gc-x-workstation-gc/ http://www.zezologs.org/blog/server-gc-x-workstation-gc/#comments Tue, 18 Dec 2007 15:51:11 +0000 eudescosta http://www.zezologs.org/blog/2007/12/18/server-gc-x-workstation-gc/ Vários artigos sobre performance em .net sugerem que dependendo da aplicação o algoritmo no GC seja alterado…

Se é uma aplicação desktop (tipo Windows forms) ele aconselha o uso do Workstation GC (Mscorwks.dll).Se for uma aplicação servidor ele aconselha o uso do Server GC (Mscorsvr.dll).

No caso do Server GC ele so funciona em um servidor dual processor, pq ele cria dois GC heaps, um pra cada processador.

O Server GC é “tunado” para otimizar: throughput, comsumo de memória e fornece a escalabilidade que o dual processor deve prover….se ele for dual processor e usarmos o Workstation GC ele vai usar a aplicação como se tivesse só um processador….

Pra saber qual o algoritmo GC que sua aplicação esta usando é fácil vá no console do windows e digite:

tasklist /m mscorwks.dll

Ele deverá lhe mostrar isto:

Image Name                   PID Modules
========================= ====== ==================
OUTLOOK.EXE                 3352 mscorwks.dll
mmc.exe                     2084 mscorwks.dll
w3wp.exe                    3436 mscorwks.dll

Para configurar sua aplicação para o modo servidor no seu arquivo de configuração adicione a linha:

<configuration>

<runtime>

<gcServer enabled=”true” />

</runtime>

</configuration>

Lembre-se que para rodar o Server GC seu servidor deverá ser dual processor.

---

leia mais...

• .NET e Contadores de Performance
• Ferramentas de Teste: JMeter

Copyright © 2007-2008 zezologs.org | Todos os direitos reservados | Acessibidade | WordPress

Vários artigos sobre performance em .net sugerem que dependendo da aplicação o algoritmo no GC seja alterado…

Se é uma aplicação desktop (tipo Windows forms) ele aconselha o uso do Workstation GC (Mscorwks.dll).Se for uma aplicação servidor ele aconselha o uso do Server GC (Mscorsvr.dll).

No caso do Server GC ele so funciona em um servidor dual processor, pq ele cria dois GC heaps, um pra cada processador.

O Server GC é “tunado” para otimizar: throughput, comsumo de memória e fornece a escalabilidade que o dual processor deve prover….se ele for dual processor e usarmos o Workstation GC ele vai usar a aplicação como se tivesse só um processador….

Pra saber qual o algoritmo GC que sua aplicação esta usando é fácil vá no console do windows e digite:

tasklist /m mscorwks.dll

Ele deverá lhe mostrar isto:

Image Name                   PID Modules
========================= ====== ==================
OUTLOOK.EXE                 3352 mscorwks.dll
mmc.exe                     2084 mscorwks.dll
w3wp.exe                    3436 mscorwks.dll

Para configurar sua aplicação para o modo servidor no seu arquivo de configuração adicione a linha:

<configuration>

<runtime>

<gcServer enabled=”true” />

</runtime>

</configuration>

Lembre-se que para rodar o Server GC seu servidor deverá ser dual processor.

---

leia mais...

• .NET e Contadores de Performance
• Ferramentas de Teste: JMeter

Copyright © 2007-2008 zezologs.org | Todos os direitos reservados | Acessibidade | WordPress ]]> http://www.zezologs.org/blog/server-gc-x-workstation-gc/feed/ 0 http://www.zezologs.org/blog/identificando-gargalos-em-net-com-contadores-de-performance/ http://www.zezologs.org/blog/identificando-gargalos-em-net-com-contadores-de-performance/#comments Wed, 05 Dec 2007 20:10:32 +0000 eudescosta http://www.zezologs.org/blog/2007/12/05/identificando-gargalos-em-net-com-contadores-de-performance/ O próprio windows vem com uma ferramenta para indentificar gargalos em .net, o nome desta ferramenta é “Performance” …fica em: Painel de Controle – Ferramentas Administrativas – Performance.

Nao sei se muitos usam essa ferramenta, eu já usei anteriormente mas nunca notei que ele tinha contadores de performance para .NET

Alguns artigos indicam o uso desta ferramenta para identificar gargalos em aplicações .NET para então com uso de outras ferramentas (profillers) atacar a causa raiz.(Em um futuro momento farei algumas apresentações de profilers que uso e usei)

Os contadores para estas analises são:

Memory Process\Private Bytes
.NET CLR Memory\% Time in GC
.NET CLR Memory\# Bytes in all Heaps
.NET CLR Memory\# Gen 0 Collections
.NET CLR Memory\# Gen 1 Collections
.NET CLR Memory\# Gen 2 Collections
.NET CLR Memory\# of Pinned Objects
.NET CLR Memory\Large Object Heap size
Working Set Process\Working Set

Exceptions
.NET CLR Exceptions\# of Exceps Thrown /sec

Contention
.NET CLR LocksAndThreads\Contention Rate / sec
.NET CLR LocksAndThreads\Current Queue Length

Threading
.NET CLR LocksAndThreads\# of current physical Threads
Thread\% Processor Time
Thread\Context Switches/sec
Thread\Thread State

Code Access Security
.NET CLR Security\Total Runtime Checks
.NET CLR Security\Stack Walk Depth

Fontes:
http://www.codeproject.com/dotnet/perfcounter.asp
http://channel9.msdn.com/wiki/default.aspx/PerformanceWiki.HowToTuneNETFramework
http://msdn2.microsoft.com/en-us/library/ms998579.aspx

---

leia mais...

• Definindo Requisito-Não Funcional de Performance
• Server GC x Workstation GC
• Dicas: Firebug e YSlow
• Testlink: Exportação de Casos de Teste
• Testes Unitários com componente do .NET

Copyright © 2007-2008 zezologs.org | Todos os direitos reservados | Acessibidade | WordPress

O próprio windows vem com uma ferramenta para indentificar gargalos em .net, o nome desta ferramenta é “Performance” …fica em: Painel de Controle – Ferramentas Administrativas – Performance.

Nao sei se muitos usam essa ferramenta, eu já usei anteriormente mas nunca notei que ele tinha contadores de performance para .NET

Alguns artigos indicam o uso desta ferramenta para identificar gargalos em aplicações .NET para então com uso de outras ferramentas (profillers) atacar a causa raiz.(Em um futuro momento farei algumas apresentações de profilers que uso e usei)

Os contadores para estas analises são:

Memory Process\Private Bytes
.NET CLR Memory\% Time in GC
.NET CLR Memory\# Bytes in all Heaps
.NET CLR Memory\# Gen 0 Collections
.NET CLR Memory\# Gen 1 Collections
.NET CLR Memory\# Gen 2 Collections
.NET CLR Memory\# of Pinned Objects
.NET CLR Memory\Large Object Heap size
Working Set Process\Working Set

Exceptions
.NET CLR Exceptions\# of Exceps Thrown /sec

Contention
.NET CLR LocksAndThreads\Contention Rate / sec
.NET CLR LocksAndThreads\Current Queue Length

Threading
.NET CLR LocksAndThreads\# of current physical Threads
Thread\% Processor Time
Thread\Context Switches/sec
Thread\Thread State

Code Access Security
.NET CLR Security\Total Runtime Checks
.NET CLR Security\Stack Walk Depth

Fontes:
http://www.codeproject.com/dotnet/perfcounter.asp
http://channel9.msdn.com/wiki/default.aspx/PerformanceWiki.HowToTuneNETFramework
http://msdn2.microsoft.com/en-us/library/ms998579.aspx

---

leia mais...

• Definindo Requisito-Não Funcional de Performance
• Server GC x Workstation GC
• Dicas: Firebug e YSlow
• Testlink: Exportação de Casos de Teste
• Testes Unitários com componente do .NET

Copyright © 2007-2008 zezologs.org | Todos os direitos reservados | Acessibidade | WordPress ]]> http://www.zezologs.org/blog/identificando-gargalos-em-net-com-contadores-de-performance/feed/ 0