No Jmeter, o elemento Thread Group trata a carga do teste (workload) de um modo simples, multiplicando o número de usuários virtuais (Threads) pela quantidade de iterações (Loop Count). Se precisarmos de um cenário mais específico, como iniciar N iterações ao servidor por uma unidade de tempo, é preciso utilizar o plugin Arrivals Thread Group.
Um exemplo: saber como um sistema de vendas se comporta ao receber 10 pedidos de compras (iterações) por segundo (unidade de tempo) durante um período de tempo deve ser implementado com o plugin Arrivals Thread Group.
Um fluxo hipotético para submeter uma compra em um site, seria:
- Ir para página inicial
- Buscar um produto
- Comprar o produto
Uma iteração necessariamente passa por todos os passos descritos anteriormente.
Utilizando o plugin Arrivals Thread Group
Em qualquer sistema, quanto maior o número de requisições por uma unidade de tempo, maior o tempo de resposta do sistema. Em um teste de performance, quanto maior o tempo de resposta, maior o tempo que o usuário virtual (Thread) leva para finalizar a iteração. O plugin Arrivals Thread Group está preparado para lidar com essa situação durante a execução do teste para manter a taxa alvo (Target Rate) de arrivals (iterações).
O plugin altera o número de usuários virtuais (Threads) para buscar manter a vazão (Target Rate). Vejamos este plugin em ação; a taxa alvo de iteração é o valor de 10 arrivals (iterações) por segundo. Não é especificado o número de usuários virtuais (Threads), este número varia conforme o plugin necessite para manter a vazão do teste.
- Além da taxa alvo de iterações (Target Rate), é opcional escolher o Ramp-up, uma quantidade de tempo que o plugin terá até atingir o número da taxa alvo de iterações. Escolhi 60 segundos.
- Também é opcional escolher o Ramp-up Steps Count, um número de passos no qual ocorrerá incrementos no número de iterações durante o período de Ramp-up – escolhi dois.
- Observando o gráfico, durante os 30 primeiros segundos, apenas cinco iterações por segundo são iniciadas, pois o plugin dividiu Ramp-up/Ramp-up Steps Count (60 / 2).
- A taxa alvo de iterações (10 arrivals/sec) ocorrerá pelo valor de Hold Target Rate Time, 60 segundos.
- O tempo total do teste será Ramp Up Time somado a Hold Target Rate Time, 120 segundos.
Para construir o caso de teste de compra conforme definido anteriormente, adicionei três requisições Dummy Sampler (plugin) para realizar a iteração de compra. Escolhi as requisições Dummy Samplers para ter o controle sobre o tempo de resposta. Manipularei os tempos de resposta para demonstrar o plugin em ação.
O tempo de resposta será incrementado via código Groovy para demonstrar o plugin reagindo e incluindo mais Threads para manter a vazão do teste. Simplificando, utilizo uma requisição Dummy Sampler para atingir a Página Inicial, a segunda para pesquisar um produto, e a terceira para comprar o produto.
A compra de um produto é um evento único e não pode ser cacheada. Por essa razão, escolhi essa requisição para manipular o tempo de resposta via código Groovy. Nesta requisição o tempo de resposta é definido por:
${__property(pResponseTime,vResponseTime,${__Random(1800,2000)})}
O significado dessa função __property é ler o valor da propriedade pResponseTime e colocá-la na variável vResponseTime. Se não houver valor na propriedade pResponseTime, será escolhido um valor randômico entre 1800 e 2000 para o tempo de resposta.
A propriedade pResponseTime é iniciada sem valor, logo, será utilizado o valor randômico até a propriedade ser valorada. Um código Groovy foi utilizado em um JSR223 PostProcesssor relacionado ao Dummy Sampler “03 – Comprar produto” para manipular o tempo de resposta. Este código é executado após essa requisição realizada.
O código está aqui:
long iterationCount = ${__counter(FALSE,)}//contador de iterações
long vResponseTime = Long.parseLong(vars.get("vResponseTime"));
log.info("Response Time Variable ${vResponseTime}")
if (iterationCount > 450) {
vResponseTime = vResponseTime + 100
props.put ("pResponseTime", String.valueOf(vResponseTime))
}
Conforme o gráfico gerado pelo plugin, no total serão 1050 arrivals (iterações) realizadas pelo teste. Durante os 30 primeiros segundos, ocorrerão cinco arrivals (iterações) por segundo chegando ao servidor. No marca de tempo de 30 segundos há um incremento para 10 arrivals/segundo, e já ocorreram 150 iterações (30 segundos x 5 arrivals/segundo).
No código Groovy do JSR223 PostProcessor, a variável iterationCount serve como um contador do número de iterações. Se o valor que a variável iterationCount possui é maior que 450 (iterações), a condição desperta o código para incrementar a variável vResponseTime em 100 milissegundos. Este valor da variável é colocado na propriedade pResponseTime.
Na próxima vez que o Dummy Sampler “03 – Comprar produto” calcular o tempo de resposta, usará o valor da propriedade pReponseTime e colocará o valor em vResponseTime. Assim, a partir desta requisição, todas as demais requisições “03 – Comprar produto” utilizarão o valor da propriedade pResponseTime incrementado em 100 milissegundos.
O tempo de resposta do Dummy Sampler “03 – Comprar produto” (linha verde), aumenta continuamente após após a iteração 450 em torno do 1:08 minuto, devido ao código do PostProcessor JSR223, isso afetaria a vazão do do teste, pois cada usuário leva mais tempo para concluir a iteração, mas o plugin reage aumentando o número de Threads.
O plugin necessitou ao redor de 23 threads para manter a taxa alvo (Target Rate) de 5 arrivals/segundo durante os 30 primeiros segundos, e em torno de 47 Threads para manter a taxa alvo de 10 arrivals/segundo. Após 1:08, o tempo de resposta total da iteração começa a aumentar via código Groovy e cada Thread se mantém por mais tempo ocupada (ativa). Logo, é necessário um aumento no número de Threads para cumprir a demanda de 10 iterações por segundo.
Houveram 1051 requisições de “01 – Home”. Entretanto, houveram somente 1042 requisições de “02 – Buscar produto” e 1025 requisições de “03 – Comprar produto”. Isso ocorre porque somente há garantia de que as iterações sejam iniciadas, se as requisições da iteração não tiverem sido enviadas e o tempo (Hold Time Rate Target) acabar. Essas requisições faltantes não serão enviadas.
O total de iterações do teste também é influenciado pelos campos Thread Iterations Limit e Concurrency Limit. O primeiro campo a limita a quantidade de iterações por Thread. O segundo campo limita a quantidade de Threads, este campo deve ser usado para evitar a possibilidade de exaustão da memória durante o teste.
Referências
De 0 a 10, o quanto você recomendaria este artigo para um amigo?