Dimensionamento de Usuários Simultâneos para Testes de Estabilidade no Apache JMeter

Fundamentos do Teste de Estabilidade

O teste de estabilidade, também conhecido como Soak Testing, visa validar o comportamento do sistema sob uma carga constante durante períodos prolongados (geralmente entre 8 e 24 horas). O objetivo principal não é encontrar o ponto de ruptura, mas sim identificar problemas que só aparecem com o tempo, como vazamentos de memória (memory leaks), saturação de pools de conexões ou fragmentação de disco.

A carga de trabalho ideal para este cenário deve refletir o estado de regime permanente (steady state), situando-se geralmente entre 70% a 100% da carga média observada em produção.

Metodologias para Cálculo do Número de Usuários

1. Aálise Baseada em Dados de Produção

Se o sistema já está em operação, a forma mais precisa de definir a carga é através da análise de telemetria e logs.

  • Identifique a média de usuários simultâneos em horários comerciais.
  • Mapeie a taxa de requisições por segundo (RPS) por funcionalidade.

Aplique o seguinte cálculo para o ambiente de teste:


// Exemplo de definição de carga baseada em produção
usuarios_teste = usuarios_simultaneos_prod * fator_estabilidade;
// Onde fator_estabilidade varia entre 0.7 e 1.0

2. Estimativa para Novos Sistemas (Modelo Probabilístico)

Quando não há dados históricos, utiliza-se uma projeção baseada no comportamento esperado do público-alvo.


// Projeção de usuários para novos lançamentos
Threads_Totais = (Base_Usuarios * Percentual_Ativos * Taxa_Simultaneidade) * Margem_Seguranca;

  • Base_Usuarios: Total de usuários cadastrados.
  • Percentual_Ativos: Porcentagem de usuários que acessam o sistema diariamente (ex: 15%).
  • Taxa_Simultaneidade: Porcentagem de usuários ativos que realizam ações ao mesmo tempo (ex: 5%).
  • Margem_Seguranca: Geralmente 0.8 para evitar sobrecarga acidental no início do teste.

3. Cálculo por Taxa de Transferência (RPS/Throughput)

Se o requisito de negócio for definido por volume de transações, o número de threads no JMeter deve ser derivado da latência esperada.


// Determinação de threads via throughput alvo
Numero_Threads = (RPS_Alvo * Tempo_Resposta_Medio_Segundos);

Por exemplo, se a meta é sustentar 50 RPS e o tempo de resposta médio é de 2 segundos, seriam necessárias ao menos 100 threads operando sem pausas.

Processo de Validação Progressiva

Antes de iniciar a execução de longa duração, é crucial realizar uma fase de calibração:

Fase de Ramp-up Escalonado

Utilize um Stepping Thread Group para aumentar a carga gradualmente em ciclos curtos (ex: 15 a 30 minutos por degrau). Observe os seguintes indicadores:

  • Ponto de Inflexão: Onde o tempo de resposta começa a subir exponencialmente.
  • Taxa de Erro: Deve permanecer abaixo de 0.1% durante a estabilidade.
  • Consumo de Recursos: CPU e Memória devem estabilizar, não apresentar crescimanto linear infinito.

O número de usuários para o teste de estabilidade definitivo deve ser definido como 70% do ponto de saturação identificado nesta fase.

Configurações Essenciais no Script JMeter

Para garantir a validade técnica do teste de longa duração, aplique estas práticas no seu plano de teste:

  • Gerenciamento de Timer: Use o Gaussian Random Timer ou Uniform Random Timer para simular o "Think Time" humano entre as ações, evitando que o teste se torne um ataque de negação de serviço (DoS).
  • Parametrização: Utilize o CSV Data Set Config com uma massa de dados ampla para evitar que o cache do banco de dados mascare problemas de performence de I/O.
  • Monitoramento de JVM: Acompanhe o comportamento do Garbage Collector. Frequências excessivas de Full GC indicam que a carga de usuários está alta demais para a memória disponível ou que há falhas na gestão de objetos.
  • Limpeza de Conexões: Verifique se o JMeter está configurado para encerrar e reabrir conexões HTTP conforme o comportamento real dos navegadores, evitando a persistência artificial de sockets.

Critérios de Sucesso

Um teste de estabilidade é considerado bem-sucedido quando:

  1. A taxa de erro acumulada é insignificante (próxima a 0%).
  2. O uso de memória RAM após o teste retorna aos níveis iniciais ou estabiliza em um patamar aceitável (sem vazamentos).
  3. A variação do tempo de resposta (Standard Deviation) entre o início e o fim do teste é inferior a 10%.

Tags: JMeter performance-testing load-testing quality-assurance devops

Publicado em 8-1 00:43