Teste de carga e estresse

Teste de carga e estresse

1) Por que é necessário

• Confirmar a capacidade (quantos RPS/sessões competitivas o sistema aguenta com o SLO especificado).
• Encontrar os gargalos de garrafa (CPU/IO/BD/rede/bloqueio/pula).
• Configure os orçamentos de performance e «gates» em CI/CD.
• Reduzir o risco de lançamento (regressão p95/p99, aumento de erros no pico).
• Planejar capacidade/custo (skale-out e reservas).

2) Tipos de teste de perf

Load (carga de trabalho): tráfego realista próximo a picos; validação do SLO.
Stress: Crescimento até/acima do limite → comportamento na degradação onde se rompe.
Spike (impulso): elevação rápida da carga → elasticidade/scail automático.
Soak/Endurance (longo): relógio/dia → fugas, fragmentação, à deriva latency.
Capacity/Escalability: Como o throughput/latency para scale-out muda; a Lei Amdahl/Gustafson.
Smoke perf: uma breve «fumaça» em cada lançamento (performance-saniti).

3) Modelos de geração de tráfego

Modelo fechado (fixed VUS/concurrency): 'N' usuários, cada um faz solicitações → filas no cliente. Risco de encobrir sobrecarga.
Modelo aberto (arrival rate): fluxo de solicitação com intensidade de £ (req/s), como na vida real. Mais correto para APIs públicas.

A Lei Little é 'L = £ x W'.
Para o pool/serviço: paralelismo mínimo ≈ '£ x W' (adicione 20% a 50% da reserva).
Onde '£' é throughput, 'W' é o tempo médio de serviço.

4) Perfis de carga e cenários

User journal mix: proporções de cenários (login, browse, deposit, checkout...).
Think-time: pausas do usuário (distribuição: exponencial/lognormal).
Data profile: tamanho das respostas, payload, variabilidade de parâmetros.
Correlação: vincule os passos (cookies/tokens/ID) como em flow real.
Frio/quente/quente kesh: proteções individuais.
Read vs Write: equilíbrio de leitura/gravação, idempotidade para retais.
Região Multi: RPT, distribuição por POP/ASN.

5) Ambiente de testes

Isolamento: o estande está próximo da venda por topologia/configuração (mas não «bater» proda).
Dados: camuflagem PII, volumes, índices como em venda.
Geradores de carga: não se baseiam em CPU/rede; runners distribuídos, sincronização do tempo.
Observabilidade: métricas/trailers/logs, sintético no perímetro, exportação de perfis CPU/heap.

6) Métricas e SLI

Throughput: RPS/transações em segundos.
Latency: p50/p95/p99, TTFB, server time vs network.
Errors: 5xx/4xx/erros de domínio.
Saturation: CPU, load avg, GC, disco IOPs/latência, rede, pool wait.
Negócio SLI: depósito de sucesso ≤ 5s, confirmação de pedido ≤ 2s.

Os limites são de SLO (por exemplo, "99. 95% ≤ 300 ms"), monitora o burn-rate durante o teste.

7) Pesquisar estreitos (metodologia)

1. Mantenha o sistema estável entre 60% e 80% da carga de destino.
2. Aumente os estágios (ramp) → fixe onde os p95/p99 e error-rate crescem.

• filas de pool (DB/HTTP),
• Crescimento WAIT/locks (BD),
• Pausas GC/heap,
• retransmits de rede/packet loss,
• latência de disco/falhas de dinheiro.
• 4. Localiza: pesquisa binária no caminho de consulta, perfiladores (CPU/alloc/lock-profile).
• 5. Fixe a «garrafa» sintonizar a repetição.

8) Comportamento sob estresse

Graceful descradation: limites, circuito-breakers, filas com backpressure, modo «aceito em processamento».
Retrações: no máximo 1, apenas Idumpotentes; jitter; orçamento de retrações ≤ 10% do RPS.
Fail-open/Fail-closed: para dependências não-críticas, admita fail-open.
Cascading failure: isolamento de pool/cota (bulkhead), temporizações rápidas, desativação de funções «fluida» (função flags).

9) Ferramentas (seleção para tarefa)

k6 (JavaScript, aberto/open-model, rápido, conveniente em CI).
JMeter (rico em ecossistema, GUI/CLI, plugins, mas mais pesado).
Gatling (Escala DSL, alto desempenho).
Locust (Python, flexibilidade de cenário).
Vegeta/ei/wrk (micro-benchi e verificação rápida).

Regra: uma ferramenta «principal» + CLI leve para smoke-perf em PR.

10) Exemplos (snippets)

10. 1 k6 (modelo aberto com arrival rate)

js import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
scenarios: {
open_model: {
executor: 'ramping-arrival-rate',
startRate: 200, timeUnit: '1s',
preAllocatedVUs: 200, maxVUs: 2000,
stages: [
{ target: 500, duration: '5m' },  // до 500 rps
{ target: 800, duration: '5m' },  // стресс
{ target: 0,  duration: '1m' }
]
}
},
thresholds: {
http_req_duration: ['p(95)<300', 'p(99)<800'],
http_req_failed: ['rate<0.005'],
},
};

export default function () {
const res = http.get(`${__ENV.BASE_URL}/api/catalog?limit=20`);
sleep(Math.random() 2); // think-time
}

10. 2 JMeter (ideia de perfil)

Thread Group + Stepping Thread или Concurrency Thread (open-like).
HTTP Request Defaults, Cookie Manager, CSV Data Set.
Backend Listener → InfluxDB/Grafana; Assertivas em tempo/código.

10. 3 Locust (Python)

python from locust import HttpUser, task, between class WebUser(HttpUser):
wait_time = between(0.2, 2.0)
@task(5)
def browse(self): self.client.get("/api/catalog?limit=20")
@task(1)
def buy(self): self.client.post("/api/checkout", json={"sku":"A1","qty":1})

11) Dados, correlação, preparação

Dados Seed: diretórios, usuários, balanços, tokens - como em venda.
Camuflagem/anonimato PII; geração de sintéticos acima das distribuições reais.
Correlação: retire o ID/tokens das respostas (RegExp/JSONPath) e use nos passos seguintes.

12) Observabilidade durante os testes

RED-dashboards (Rate, Errors, Duration) sobre rotas.
Excempars: transição de métricas para trilhas (trace _ id).
Logs de erro: sampling + agregação, duplicação/idempotidade.
Sistema: CPU/GC/heap, disco/rede, pool wait.
BD: melhores pesquisas, bloqueios, índice scan, bloat.

13) Automação e performance-gate

CI: Pautas curtas em merge (por exemplo, k6 2-3 minutos) com liminares.
Nightly/Weekly: longos soak/stress em ambientes separados; relatórios e tendências.
Lançamentos de canário: análise SLO (erro-rate, p95) como «gate» promoção.
Regressão: baseline vs bild atual; alertas de deterioração> X%.

14) Planejamento de capacidade e custo

Curvas de throughput→latency: defina knee point (joelho) - depois disso, p99 cresce drasticamente.
Scale out: Mede a eficácia de zoom (delta RPS/delta de nós).
Valor: «RPS por $/hora», reserva para eventos de pico + DR.-reserva.

15) Anti-pattern

Bater em uma proda sem controle ou testar em um ambiente «vazio» que não se parece com uma proda.
Um modelo fechado, com VU fixo, que esconde a sobrecarga.
A falta de think-time/dados → hits irrealistas de kesha ou vice-versa - tempestade de origem.
Um cenário «/ping »em vez de flow personalizado.
«Só vemos RPS e atraso médio».
Retraias descontroladas → si-DDoS.
Misturar teste e otimização sem fixar hipóteses/alterações.

16) Folha de cheque (0-30 dias)

0-7 dias

Defina o SLI/SLO e os perfis de tráfego de destino (mix, think-time, dados).
Selecione a ferramenta (k6/JMeter/Locust) e levante os dashboards RED.
Prepare o estande e os dados de seed, desliga os limites de terceiros/captchi.

8-20 dias

Construa cenários: open-model (arrival rate), frio/quente/quente kesh.
Inicie o load → stress → spike; fixe o knee point e os pontos mais estreitos.
Introduza o desempenho-gate no CI (micro-progon).

21-30 dias

Teste Soak 4-24 h: fuga/deriva GC, estabilização.
Documente os limites, o plano de capacidade, a ilustração «RPS→p95/oshibki».
Prepare o runbook «como aumentar os limites/scale» e «como degradar».

17) Métricas de maturidade

Há perfis realistas (mix, think-time, dados) que cobrem ≥ 80% do tráfego.
RED-dashboard + rastreamento estão ligados para todos os testes.
O desempenho-gate bloqueia os lançamentos ao regredir p95/erros.
Capacidade e knee point documentados através de serviços essenciais.
Ups mensais soak/stress e relatórios de dinâmica.
A resistência a «spike» é confirmada por um skate automático e falta de cascade-fail.

18) Conclusão

Um teste de carga é uma prática regular de engenharia, não uma medição única. Modele os usuários reais (open-model), mede o que reflete a experiência do cliente (SLI/SLO), mantenha a observabilidade e os «gates» em CI/CD, realize stress/spike/soak-upons e instale knee point. Então, os eventos de pico e os cisnes negros se transformam em cenários controláveis, e a produtividade é um parâmetro previsível e mensurável da sua plataforma.