Testes de carga e perfis de stress

Resumo curto

O teste de carga é um teste de desempenho e estabilidade do sistema sob cenários realistas e extremos. Base de sucesso: modelo de tráfego correto (open vs closed) fixado por SLO, métrica pura (latency/throughput/erro/saturação), dados representativos, automação e repetibilidade. O resultado não é «RPS», mas sim uma solução: onde estão os pontos estreitos, quanto custa a produtividade, onde está o limite de rejeição e como movê-lo.

SLO/SLI e métricas de destino

SLO (exemplo): p95 API ≤ 250 ms, p99 ≤ 600 ms; erro ≤ 0. 3 %/30 dias.
SLI: latency (p50/p95/p99), throughput (RPS/CPS/QPS), saturation (CPU/heap/GC/FD/conn), ошибки (5xx, timeouts), очереди (depth/lag), DB (locks, slow queries), кэш (hit-ratio).
Acervos de erro e desencadeadores de saturação (por exemplo, CPU> 75% ou queue depth> X → degradação).

Tipos de testes

1. Baseline/Benchmark - um único serviço/endpoint, condições «perfeitas».
2. Load é um «dia de trabalho» realista + ramp-up/ramp-down.
3. Stress - Aumentamos a carga para degradação e fixação de breakpoint.
4. O Spike é um salto abrupto (x2-x10 em segundos/minutos).
5. Soak/Endurance - longa duração (8-72 h): fuga de memória, à deriva de latência.
6. O Capacity é uma carga de passo para criar uma curva de desempenho e planejar a capacidade.
7. Degradation/Chaos-mix - carga + falhas parciais (BB lento, queda de cachê, aplink «batido»).

Modelos de tráfego: Open vs Closed

Open Model (mais realista para a Internet): os usuários vêm com uma intensidade de £ (Poisson-semelhante). Se o sistema parar, as solicitações são acumuladas em vez de «congeladas».
O Closed Model é um número fixo de usuários virtuais com think-time. Quando a demora aumenta, o RPS cai artificialmente - cuidado com as conclusões.
Recomendação: para API de frente, use open model (k6 'arrival-rate') e para cenários sincronizados internos - combine com closed.

Perfis de carga (modelos)

«Dia normal»: Fundo básico + oscilações diurnas.
«Pic-ivent»: 10-30 min antes da partida (aquecimento), spike brusca na partida, plataforma, cauda.
Torneio/estrim: madeireira de degraus, picos repetidos em intervalos.
«Degradação da infraestrutura»: metade da caixa está vazia, uma região desligada, aumento da latência PSP.
«Failover»: o tráfego desloca para uma reserva de 1 a 5 minutos; verificamos o skale automático/HPA/Retry-tempestades.

Dados e preparação do ambiente

Dados de teste: cardinalite realista (provedores, moedas, países), campos «sujos», distribuição de solicitações (Pareto/Zipf).
Segredos/PII: Anonimato; chaves/PSP - sandbox.
Ambiente: estande perf selecionado, isolamento de integração (mock/manadas), versões fixas.
Observabilidade: métricas (Prometheus), logs (Loki/ELK), pistas (OTTEL). Capture o build-id nas respostas.

Anti-shthrama de retrações e idempotação

Retraias apenas para operações idumpotentes; coloque retry-budget (por exemplo, ≤ 10% do tráfego).
Exponential backoff + jitter; «collapsing» idêntico ao GET.
Para pagamentos, chaves idumpotentes e estatais explícitas.
Proteção contra thundering herd: cash looks, SWR, semaforas locais.

Ferramentas e pattern

k6 (violino, open-model, bons relatórios), Locust (cenários Python), Gatling (Escala), JMeter (ampla gama de protocolos).
Protocolos: HTTP/1. 1/2/3, gRPC, WebSocket, TCP/UDP; Não testem «como GET» o servidor pool.
Geração de tráfego: escala horizontal de geradores, controle de estreito de rede.
Comendo os perfis pprof/async-profiler/ebpf sob carga, pistas OTEL.

Mini-exemplo k6 (open-model + spike):

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

export const options = {
scenarios: {
warmup: { executor: 'ramping-arrival-rate', startRate: 50, timeUnit: '1s',
preAllocatedVUs: 200, stages: [ { target: 200, duration: '5m' } ] },
spike: { executor: 'constant-arrival-rate', rate: 1200, timeUnit: '1s',
preAllocatedVUs: 2000, startTime: '6m', duration: '3m' }
},
thresholds: {
http_req_failed: ['rate<0. 3%'],
http_req_duration: ['p(95)<250', 'p(99)<600']
}
};

export default function () {
const res = http. get(`${__ENV. BASE_URL}/api/v1/catalog? c=${Math. floor(Math. random()1000)}`);
check(res, { 'status is 200': (r) => r. status === 200 });
sleep(Math. random()0. 9) ;//think time (for closed parts of the script)
}

Metodologia de execução

1. Hipótese de que estreitos são prováveis (CPU, BD, dinheiro, rede, TLS, GC).
2. Perfil → cenários/rotas, proporções de tráfego, modelos (open/closed), dados.
3. Aquecimento → dinheiro/conectórios/TLS/intérpretes.
4. Cresce o → estágio para a intensidade de destino.
5. Plataforma → coleta de métricas estáveis e pistas.
6. Estresse/declínio → localização de ponto de desgaste, observação de skate automático.
7. Análise → correlação de métricas, flamegraph, relatório e planilha de alterações.
8. Repexe → repetição através do pipline CI (Regision Perf).

Análise de resultados

Curva de carga → atraso/erro: procure o joelho (capacity).
Breakdown laticínios: rede (DNS/TLS/connect), proxy, aplicativo, banco de dados, chamadas externas.
Saturação: CPU> 75-85%, GC pause> p95, I/O-espera, fila de tarefas.
Elasticidade: Tempo de reação do skale automático (HPA/KEDA), «início frio», aquecimento do cachê.
Custo: $/1000 RPS com o SLO alvo, previsão de orçamento para o pico.

Práticas de engenharia

Indicadores de degradação: «caudas» p99, aumento de filas, queda de hit-ratio, aumento de tentativas de retrações.
Exclua os confounders: limites de descriptor de arquivos, sysctl, conn-pool, 'reuseport', TLS, OCSP.
BD: índices/planos/dinheiro de solicitação, pool de conexões, operações de batch, backpressure para os produtores.
Cachês: tamanho/evition-política, chaves quentes, replicação.
Rede/edge: HTTP/2/3, resumption≥70%, Brotli, CDN-chave de cachê, tiered-cache.

Observabilidade sob carga

Métricas: sistema (CPU/mem/IO), runtime (GC/heap), rede (RPT/loss/ECN), L7 (p95/99, 5xx/429), filas, clusters BD/dinheiro.
Trailers: inclua a semente em «caudas» (tail-based), marca build-id/canários.
Logi: agregação de erros de limitação de volume (para não «DOSOU» logs-pipline).
As experiências de função-flags e configs devem ser registradas no relatório.

Automação e CI/CD

Perf-jobs em CI (smoke 3-5 min, nightly 30-60 min, week soak).
Os limites de tolerância são latência/erros/recursos → "quebramos o bild' ao regredir.
Artefatos: gráficos, flamegraphs, perfis, relatórios JSON (k6/jtl).
Versionagem de dados e de cenários, revezamento de parafusos.

Especificidades para iGaming/Fintech

Torneios/jogos: spike + plateau; progressos TLS/DNS/CDN, limites de pool elevados, rotas «cinzentas» para bots.
Pagamentos/PSP: limites sandbox, idempotidade, tempo rigoroso; verificação de degrade-modo (dinheiro de guias, filas).
Jackpots/iventes: atômica e sequência, falta de dublês, carga de RNG/liderbords.
Antifrod/AML: carga de regulamento/ML, backpressure, dedução de eventos.
Regulação: regulação de métricas e versões em picos, relatórios de auditoria.

Folha de cheque de início

Registado SLO/SLI e «linhas vermelhas» (erro/latência/saturação).
Os cenários e perfis de carga foram aprovados (open/closed, spike/soak/stress).
Dados realistas, PII disfarçado, integração - sandbox/mock.
Observabilidade pronta: métricas/trens/logs, marcas de lançamento.
Os configs de sistemas (ulimit/sysctl/pools) estão documentados.
Plano de skale/aquecimento automático e critérios rollback.
Alertas de limiar e plano de comunicação de comandos (on-call).
O modelo revisado (gráficos, conclusões, ações) foi preparado.

Erros típicos

O teste closed-model produz o resultado verde e a proda cai (não é possível ignorar o modelo aberto).
Dados não representativos (uma moeda/um provedor) → conclusões falsas.
Preparação zero: cachês frios/TLS/conectórios → latidão exagerada no início.
Retraias sem limites → tempestade e queda em cascata.
Os mesmos perfis para todos os serviços → a omissão de pontos quentes reais.
Falta de protecção soak → vazamento de memória e à deriva.
Resultados opacos: sem trilhos/flaymógrafos → não é possível localizar um local estreito.

Mini-playbooks

Definição de largura de banda limite (breakpoint)

1. Degraus de 10% a 20% de carga a cada 5-10 min 2) Registramos o momento em que p95 cresce drasticamente e erros> SLO. 3) Retire os perfis CPU/BD/cachê. 4) Plano de otimização e repetição.

Contenção de tempestades de retrações

1. Limitar retry-boodget e incluir backoff + jitter. 2) Digite request-collapsing/SWR. 3) Permitir «modo degrado» (função limitada). 4) Redefinir Idempotidade.

Pico Ivent (torneio) - pré-plano

1. Aqueça CDN/DNS/TLS/pool. 2) Aumentar o HPA target, preparar a reserva. 3) Limites rate individuais para bots. 4) Dashboards de modo de ponta, ponte de ligação on-call.

Soak-noite

1. 8-12 horas de carga estável. 2) Monitor heap/FD/conn/GC-paes. 3) Cruzando delta p95 e hit-ratio. 4) Registando fugas e à deriva.

Resultado

O teste de carga é um processo de engenharia, não uma corrida RPS. Modele perfis reais (especialmente o modelo aberto), fixe SLO, retire métricas e pistas, procure o joelho de desempenho e leia o custo de desempenho. Automatize os testes, mantenha os retais anti-tempestade e planeje eventos de pico - para que a plataforma seja previsível e sustentável nos momentos mais tensos.