Posts Tagged ‘JMeter’

JMeter na prática: teste de carga no IBM WebSphere Portal

Recentemente escrevi sobre como fazer uma configuração no JMeter para fazer teste de carga no IBM WebSphere Portal.

Abaixo, vou demonstrar resultados práticos de 2 planos de testes.

Plano de Teste Simples

Neste Plano de Teste foi configurado uma Thread Group com apenas 20 usuários.

Test Plan 01 - Thread Group

Test Plan 01 - Thread Group

Veja o Summary Report deste Plano de Teste.

01_sumary_report

Summary Report

Plano de Teste mais “puxado”

Os resultados que serão apresentados abaixo são referentes a uma configuração de um Thread Group com 500 usuários e tempo de ZERO segundos, ou seja, simulado 500 requisições simultâneas.

Nessa configuração, o Summary Report apresentou os resultados abaixo.

Summary Report com 500 usuários

Summary Report com 500 usuários

Este Plano de Teste executou 90.000 “samples” num tempo de aproximadamente 2 minutos.

Simultaneamente, verifiquei as informações apresentadas pelo “server-status” disponível no servidor IBM HTTP Server.

IBM HTTP Server - Status

IBM HTTP Server - Status

É bom SEMPRE fazer um bom teste de carga antes de liberar seu site para produção. Antes, porém, faça as devidas configurações de “tunnig” em seu produto.

Hoje, para que possam ter uma idéia, verifico um máximo de 120 requisições simultâneas, bem menos das 500 configuradas no Plano de Teste.

Esse tipo de teste é uma boa garantia a ser apresentada para seu cliente para configurar os trabalhos realizados pela equipe técnica.

Configurando o JMeter para Stress Test no Portal Server

Escolhi o Apache JMeter para teste de carga no IBM WebSphere Portal. Como mencionado no post anterior, há outros softwares que poderiam ser utilizados.

Plano de Teste

A primeira coisa que precisamos preparar no JMeter é o Test Plan (Plano de Teste). Renomearemos este para “Plano de Teste”.

Apache JMeter

Apache JMeter

Em um plano de teste podemos adicionar 1 ou mais Thread Group. Em nosso plano de teste, adicionaremos apenas um Thread Group.

Adicionar Thread Group

Adicionar Thread Group

Neste Thread Group é onde definiremos a quantidade de threads (usuários), o tempo de execução de cada um e a quantidade de repetições.

Thread Group - Configurações

Thread Group - Configurações

O atributo “Number os Threads (users)” indica a quantidade de usuários/requisições que nosso plano de teste comportará. Neste caso  defini 100 threads a serem executadas.

O atributo “Ramp-Up Period (in seconds)” indica os segundos em que cada Thread será executada. Quando este valor estiver em ZERO, indica que TODAS as Threads serão automaticamente iniciadas.

O atributo “Loop Count” indica as repetições. Neste caso defini 100 repetições.

Essas configurações indicam que teremos 100 repetições de 100 Threads executadas simultaneamente. É um valor considerável. Recomendo que você inicie com 1 Thread e vá aumentando: 5, 10, 20, 50, 100… É uma boa maneira de você medir seu produto e servidor sem maiores danos. Não esqueça de verificar as configurações de seu servidor HTTP também.

Configurar Elementos HTTP

Bom, até agora não mencionamos nada do IBM WebSphere Portal Server. Mas agora começa a parte legal disso tudo. Precisaremos adicionar 4 elementos de configuração:

- HTTP Request Defaults
- HTTP Cookie Manager
- HTTP Header Manager
- HTTP Authorization Manager

HTTP Request Defaults

Neste elemento de configuração, defina as informação referentes a “Web Server”. Para a informação “Server Name or IP”, informe o nome completo do seu servidor. Na informação “Port Number” digite “80″ (ou outro valor que esteja definido).

HTTP Request Defaults

HTTP Request Defaults

HTTP Cookie Manager

Neste elemento de configuração, marque a opção “Clear cookies each iteration?”

HTTP Cookie Manager

HTTP Cookie Manager

HTTP Header Manager

Neste elemento de configuração, adicione “User-Agent” com valor “Apache_JMeter_2.2″.

HTTP Header Manager

HTTP Header Manager

HTTP Authorization Manager

Neste elemento de configuração está o “pulo do gato”: a adição da URL base para autenticação do Portal.

Para a informação “Base URL” digite “/wps/portal/cxml/04_SD9ePMtCP1I800I_KydQvyHFUBADPmuQy”. Nas informações “Username” e “Password” digite valores válidos para autenticação em seu Portal.

HTTP Authorization Manager

HTTP Authorization Manager

Pronto. A partir deste ponto você definirá as requisições e os relatórios.

Configurar Requisições

As requisições são as URLs que existem em seu Portal e que você quer testar. Pode-se usar quantas modelos HTTP Request necessários, mas lembre-se que quanto mais…

HTTP Request

HTTP Request

Uma maneira simples de fazer isso é utilizando as famosas URLs Mapeadas no Portal. É o exemplificado na imagem anterior. Certifique-se de desmarcar a opção “Redirect Automatically” e marcar a opção “Follow Redirects”.

Relatórios

Onde as informações do teste de carga serão exibidos? Resposta: as informações podem ser visualizadas nos relatórios/listeners disponíveis.

Um que gosto muito de usar é o “Summary Report”, pois possui vários números como % de erros, o Throughput, média de KB trafegados, etc. Este relatório regista as Requisições (HTTP Request) em cada linha.

Summary Report

Summary Report

Você pode usar vários relatórios ao mesmo tempo, mas… CUIDADO, pois o exagero pode fazer esta humilde aplicação fechar inesperadamente. Experiência comprovada.

Não esqueça de salvar seus relatórios e seu plano de teste.

Estou AQUI

Tags
Desafie meu Brute