Técnica de Pausa (Parte 1)

O objetivo deste artigo é descrever uma técnica para especificar o ritmo de chegada dos usuários em um aplicativo web. Nota: Em inglês, a paciência é conhecida como “paciente,” que usaremos neste artigo.

O que é Pacing? #

Pacing refere-se à intervalo entre visitas a uma aplicação na Internet. Pacing representa o número de cenários de teste ocorridos em um certo período de tempo. Nota: Veja o excelente explicação do meu colega Antonio em seu blog.

Assim, Pacing representa uma exigência de forma que Pacing define o objetivo (por exemplo, visitas por hora) que um aplicativo é esperado a suportar. De fato, ele é uma criterio de aceitação das resultados da testagem de carga (outro criterio de aceitação poderia ser as respostas, por exemplo).

Incluindo Prazo na Avaliação Permite para o Regular Ritmo de Chegada ao Aplicativo e Assim Precisamente Atinge o Desejado Carregamento. Como Consequência, Isso Permite Determinar a Capacidade do Carregamento que o Aplicativo Pode Aceitar ou Suportar.

Finalmente, é importante mencionar que este método se aplica a aplicativos do tipo modos abertos onde as visitas ao aplicativo chegam independentemente (asynchronously). De um lado, essa é a característica que mais se destaca em muitos dos trabalhos realizados na Internet (por exemplo, e-commerce).

A Técnica Usando a Grupos de Fios de Chegadas #

Existem várias técnicas para implementar Pacing em JMeter, mas este artigo foca-se numa baseada no Grupo de Threads Arrivals. O que torna este TG importante é que mantém o carga (laboral) criando threads/vusers quando necessário.

Exemplos de como funciona mostramos um exemplo simples. Neste exemplo, o cliente pede que o aplicativo suporte 240 visitas/minuto. Trabalhando com o cliente, criamos o que é uma visita ou sessão:

Como demonstrado pela tabela abaixo, o encontro está composto por quatro etapas (implementadas usando um Sampler Dummy). Cada etapa é atribuída a uma Tempo de Resposta, e para as últimas três etapas, usamos uma ThinkTime constante de 2 segundos respectivamente. Além disso, utilizamos 3 analisadores para auxiliarmos na análise dos resultados.

Aqui está o diagrama que ilustra a configuração da Grupos de Threads Arrivadas. Devido à exigência de ritmo de 240 visitas por minuto, inserimos esse valor na área designada como Ritmo de Visitas (arrivadas/min). Além disso, inserimos o tempo de teste em 30 minutos na área designada como Tempo de Rituais (min).

Nota Importante: A aceleração se aplica ao todo do encontro e consequentemente a cada etapa (pedidos) da cena.

Result and Analysis #

Após a conclusão do teste, o Agregado de Relatório ouvinte exibe os seguintes resultados:

Primeiro, observamos que o número de execuções para cada passo (samples) é aproximadamente 7.200. Dividindo este número por 30 (a duração em minutos), o resultado é 240 execuções por minuto. Isso é a exigência do teste!

Como mencionamos no início, o Arrivals TG gera as Threads/VUsers necessárias para manter a carga. Para determinar esse número, podemos usar o plugin Threads por Tempo Ativo desta maneira:

De acordo com a gráfica, o número aproximado de VUsers está em torno de 64. Alternativamente, os VUsers (usuários ativos) são calculados usando uma das leis da Teoria da Colônia, a Lei de Little.

# active users = active users + paused users (ThinkTime)

# active users = (Throughput average * Response time average) + (Throughput average * Think time average)`

# active users = 15.9 * 2.5 + 15.9 * 1.5 = 63.60

Conclusão #

Embora o Grupo de Threads de Chegadas seja intuitivo e relativamente fácil de configurar, possui algumas limitações: os usuários chegam constantemente, que não é realista dado que as chegadas web são completamente arbitrárias/random. Além disso, estimar a quantidade de usuários ativos (vusers) não é um processo direto.