Testes de carga e estresse

1) Termos e objetivos

Load teste - Verificação na faixa de trabalho (target RPS/concorrência) contra SLO (por exemplo, p95 <200 ms, errador rate <0. 5%).
Stress teste - fora (antes/além da saturação CPU/BD/rede), observação da degradação e mecânica de recuperação.
Spike teste - subidas de carga bruscas (x N em minutos).
Soak/Endurance é um teste de longa duração (horas/dia) para encontrar fugas, à deriva GC, fragmentação, rodas de filas.
Capacity teste - Cálculo de plataforma de largura de banda (saturation point) e reservas.

Os objetivos são confirmar o SLO, fixar a plataforma, compreender os pontos estreitos, calibrar a escala automática e os limites.

2) Modelo de tráfego: aberto vs fechado

Modelo fechado (concurrency-driven): número fixo de usuários virtuais (VUS), cada um após responder faz um think time.
Modelo aberto (arrival-rate): intensidade fixa de solicitação (RPS), independentemente das respostas.

Little’s Law: `L = λ W`

'L' é o número médio de solicitações atendidas simultaneamente,

'a.' - intensidade (RPS),

'W' é o tempo médio de resposta.
Daí a avaliação da concorrência do gerador: 'concurrency ≈ target _ RPS p95 _ latency'.

3) Métricas: o que medimos

Atrasos SLI: p50/p90/p95/p99 e cauda p99. 9; separados para caminhos quentes e frios.
Erros: '5xx', '4xx' (validos/não validos), timeouts, aborted.
Capacidade de banda: RPS sustentável, throughput threads/bytes.
Recursos: CPU, RAM/heap, pausas GC, IOPS em disco/lat, bandwidth em rede, número de conexões/FD.
Filas e backpreser: profundidade, tempo de espera, número de consultas shed/limited.
Eficiência de cachê hit/miss, tempestades aquecidas.
BD/cachê/fila: p95 solicitações, bloqueios, conflitos, pool utilization.

4) Estandes e dados

Equivalência de configuração: versões de software, limites (uLimit, conectack), configura JVM/GC, pool's.
Topologia: LBs, CDN, WAF, TLS, os mesmos «hops» de rede.
Dados: distribuições realistas (dimensões de objetos, chaves quentes/frias, regionalidade).
Início frio/quente/quente: perfis individuais; É preciso testar cachês frios.
Isolamento de fundo: desativar jobs/cronomias não-essenciais ou considerar o seu efeito.

5) Cenários (perfis de carga)

1. Baseline: aceleração de passo para RPS alvo, retenção de 10-30 minutos

2. Ramp & Hold: crescimento suave para X% acima do alvo, retenção → análise de cauda.
3. Spike: Instantâneo x 2- x 5 pente para 1-5 min, seguido de retorno.
4. Stress to Failure: degraus antes da falha; registramos o primeiro ponto de não cumprimento do SLO e o ponto de quebra.
5. Soak: 6-24 horas com variabilidade de tráfego (dia/noite), monitorando os leques/deriva.
6. Mixed: mistura de endpoints de distribuição real (Zipf/pareto), peso diferente.

6) Passo a passo

Definir SLO e perfis de tráfego de destino.
Selecionar um modelo de carga (aberto/fechado), definir arrival-rate ou VUs.

Preparar dados e «quentes «/» frios »

Ajustar telemetria (trailers/métricas/logs), corlação com teste-rum.
Aquecimento e teste, coleta de artefatos (perfis CPU/heap, flame graphs, explain/slow-logs BD).
Análise de estreitos, formação de action items.
Reprogão pós-fixação, atualização do basline e capacity playbook.

7) Estreitos e fixações típicas

Serviço CPU-bound: perfilando → eliminando funções quentes, alocações, ramificações; vetorização, estrutura em dinheiro-friendly.
Rede/TLS: keep-alive, HTTP/2/3, conexion pooling, tempo certo, redução de bate-papo.
BD: índices, batchings, consultas preparadas, pool de conectórios, divisão R/W, cachê de resultados, dedução de solicitações.
Cachês: tamanho, TTL, request coalescing, proteção contra tempestades, warming, bolas regionais.
Filas/corretores: limites de prazer/paralelismo, tamanho de batches, idempotent consumers, tetos DLQ.
Garbatage/pausas: sintonizar GC, aluguel de buffers, object pooling dentro de limites razoáveis.
I/O/disco: entrada/saída asincrona, compressão, compressão de respostas com um nível razoável.

8) Limites e proteção

Budet temporizadores: de cima para baixo para evitar cascatas.
Rate limit/token-baquetes: degradação previsível em vez de «morte prolongada».
Circuito breaker e shading baixa prioridade na saturação.
Backpressure: sinais e limitação do paralelismo para dentro da cadeia.
Bolkheads: Isolar os poóis para endpointos críticos.
Idempotency: chaves para repetições seguras sob retais.

9) Ferramentas e quando escolhê-las

k6 - JS conciso, excelente suporte arrival-rate, integração e gráficos.
Gatling - Escala DSL, gerador de alto desempenho.
JMeter é um ecossistema flexível e rico; conveniente para protocolos/plugins.
Locust é um cenário Python, conveniente para uma lógica complexa de flow personalizado.
Vegeta/ei/wrk - Microenches e perfis pontuais em HTTP.
tc/netem, toxiproxy - injeção de degradação de rede.
Flamegraph/profiler - procurar «lugares quentes» CPU/heap.

10) Exemplos (esquetes)

k6 (modelo aberto, mix de endpoint)

javascript import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
scenarios: {
open_model: {
executor: 'constant-arrival-rate',
rate: 800, timeUnit: '1s', duration: '20m',
preAllocatedVUs: 500, maxVUs: 2000
}
},
thresholds: {
'http_req_duration{kind:hot}': ['p(95)<200'],
'http_req_failed': ['rate<0. 005']
}
};

export default function () {
const r = Math. random();
let res;
if (r < 0. 6) {
res = http. get('https://svc/api/hot', { tags: { kind: 'hot' }});
} else if (r < 0. 9) {
res = http. get('https://svc/api/warm', { tags: { kind: 'warm' }});
} else {
res = http. post('https://svc/api/heavy', JSON. stringify({ n: 1000 }), { headers: { 'Content-Type': 'application/json' }});
}
check(res, { 'status is 2xx': (r) => r. status >= 200 && r. status < 300 });
sleep(0. 2);
}

Gatling (degraus e spike)

scala setUp(
scn. inject(
rampUsersPerSec(50) to 500 during (10 minutes),
constantUsersPerSec(500) during (20 minutes),
spikeUsers(2000). during(30. seconds)
)
). protocols(http. baseUrl("https://svc"))

Plano de carga (Esqueleto YAML)

yaml profile: "mix-traffic"
targets:
- endpoint: GET /api/hot weight: 0. 6
- endpoint: GET /api/warm weight: 0. 3
- endpoint: POST /api/heavy weight: 0. 1 schedule:
- step: { rps: 300, hold: 10m }
- step: { rps: 600, hold: 10m }
- step: { rps: 900, hold: 10m }
guardrails:
slo:
p95_ms: 200 error_rate: 0. 5%
abort_if:
- metric: error_rate op: ">"
value: 2%
window: 2m

11) Automação e ciclo de vida

Perf-smoke em cada PR (curta detecção de endpoint-chave).
«Capacity» noturno é testado com relatórios e artefatos de perfis.
Gates em CI/CD: fail bild para regressão p95/p99> X% do basline ou crescimento error rate.
Versionização de basline e armazenamento de perfis/fleimógrafos como artefatos.
Tags de validade: que serviço/endpoint está coberto, qual perfil de tráfego é usado.

12) Anti-pattern

Gerador e serviço de teste em uma única máquina → resultados distorcidos.
Apenas o modelo fechado (VUs) para API-bak → subvalorização e avaliação incorreta.
Joguem um BD/cachê vazio sem um início frio.
Nenhuma distribuição realista (todas as solicitações são iguais).
Não há telemetria (apenas RPS/latency do gerador).
Comparação sem basline estável e controle do ambiente.
«Otimizar» através de um tempo maior em vez de corrigir a causa.

13) Folha de cheque do arquiteto

1. O SLO e a carga típica/pico são definidos?
2. Um modelo válido (open/closed) foi selecionado e um perfil de tráfego foi desenhado?
3. O estande é equivalente a configs e topologia, há um modo frio/quente?
4. Telemetria e perfis estão incluídos, os rótulos de teste são colocados?
5. Baseline/ramp/spike/stress/soak - coberto?
6. Os pontos de saturação são fixados e a reserva é planejada (safety margin)?
7. Limites, breakers, backprescher, idempotency, polícias de shading?
8. Tem C-gate em regresso p95/p99 e error rate, basline versionados?
9. Após a fixação - Reprogão e atualização do playbook em energia?
10. Documentou o plano de escalonamento automático e de emergência?

Conclusão

Testes de pressão e stress não são corridas individuais, mas uma prática de engenharia contínua. Um modelo de tráfego realista, estandes corretos, telemetria e automação em CI/CD transformam o desempenho em «magia secreta» em capacidade controlada por métricas: você sabe onde está o seu teto, quão seguro é o estoque e quais mudanças realmente melhoram a experiência dos usuários.