Testes de carga — Guia do usuário | YoBench

Para que serve o módulo «Testes de carga»

O módulo gera carga contra seus serviços web para você ver como se comportam sob tráfego. Dois modos: HTTP via undici em worker threads (até 500 threads concorrentes) e navegador via Chromium (até 20 abas concorrentes). As métricas atualizam a cada segundo — RPS, latência, P95/P99, taxa de erro e threads ativas.

O que você obtém:

• Alta paralelização HTTP — até 500 threads em uma máquina, sem navegador, overhead mínimo.
• Modo navegador — até 20 abas Chromium concorrentes com page.goto() e waitUntil: networkidle2, para checar render completo.
• Ramp-up — aumento gradual de threads (ramp_step_threads threads a cada ramp_step_duration segundos).
• Métricas em tempo real — um snapshot por segundo em load_test_snapshots: RPS, latência média, P95/P99, taxa de erro, threads ativas.
• Proxy e auth — cabeçalhos/cookies/parâmetros de query aplicam-se a cada requisição.
• Resultados persistidos — modelos e relatórios salvos localmente.

Parâmetros do teste

Ao criar um modelo:

• URL — obrigatória.
• Método HTTP — apenas GET por enquanto (fixo no worker).
• Cabeçalhos — do perfil de auth escolhido (método header).
• Cookies — do perfil de auth (método cookie); injetados no cabeçalho Cookie.
• Threads — 1–500 para HTTP, 1–20 para navegador.
• Duração — mínimo 5 segundos.
• Ramp-up — ramp_enabled, ramp_step_duration (s), ramp_step_threads (threads por passo). Disponível apenas no modo HTTP; o modo navegador sempre começa com todas as threads.
• Proxy — IP aleatória do grupo de proxy escolhido; auth suportada.
• Perfil de auth — entrada compartilhada das configurações.

Apenas um teste por vez — para precisão das medições.

Métricas em tempo real

Snapshots são salvos a cada segundo em load_test_snapshots:

• RPS — requisições por segundo na janela recente.
• Latência média — tempo médio de resposta (ms).
• P95 / P99 — percentis 95 / 99 da latência.
• Taxa de erro — porcentagem de respostas com falha.
• Threads ativas — threads em execução (cresce durante ramp-up).
• Requisições / erros totais — contadores cumulativos.

O relatório final inclui também P50 (mediana), Min e Max de latência.

Limites de memória para amostras de latência: HTTP — 50 000 mais recentes, navegador — 10 000.

Configurações globais

Não há chaves loadTesting* dedicadas nas configurações centrais — todos os parâmetros vivem em modelos (load_test_templates) e relatórios (load_test_reports).

Fluxo de uso

1. Crie um modelo

1. Abra o módulo Testes de carga no menu lateral esquerdo.
2. Em Modelos clique em Criar modelo.
3. Preencha URL, modo (HTTP / Navegador), número de threads, duração.
4. Opcionalmente ative ramp-up e defina os passos.
5. Escolha um grupo de proxy e um perfil de auth.
6. Salve.

2. Execute um teste

O botão Iniciar ao lado do modelo cria um relatório em running. Apenas um teste por vez. Parar encerra antes; as métricas são preservadas.

3. Veja o relatório

Na aba Relatórios cada entrada tem gráficos (RPS, latência, P95/P99, erros), números de resumo e lista por segundo de snapshots.

4. Compare execuções

Use relatórios para comparar mudanças de código / proxy / ambiente. Reexecute um modelo quantas vezes precisar — cada execução gera seu próprio relatório.

Próximos passos

• Durante o teste monitore o back-end com Servidores e Health Check.
• Use Site Audit para SEO e Lighthouse sob carga normal.
• Para verificação completa do pipeline JS escolha modo Navegador (limitado a 20 threads).

Ajuda e feedback

Quer POST/PUT/DELETE, corpos de requisição, dados aleatorizados ou carga WebSocket? Escreva para nós pelo formulário de contato.