Benchmarking e comparação de desempenho

Resumo curto

1. Configure uma hipótese e métricas.

2. Controle as variáveis (ferro, núcleo, alimentação, ruído de fundo).

3. Recolha dados suficientes (réplicas, intervalos de confiança).

4. Faça a perfilação sem que não perceba porquê.

5. Façam o repro, o registo, a fixação de versões e artefactos.

Alvos de benchmark e métricas de negócios

Banda larga (throughput): RPS/QPS/CPS, gravações/segundos.
Atraso (latency): p50/p95/p99/densidade de cauda.
Eficiência: Costa-para-1k RPS, watts por transação, $/milissegundo de melhoria.
Estabilidade: jitter, variabilidade entre ciclos/nodes.
Elasticidade: como os indicadores são escalados em N x recurso (referência Amdahl/Gustafson).

Metodologia: design da experiência

«Envoy com HTTP/3 reduz p95 TTFB entre 10% e 15% com o mesmo RPS».
Unidade de comparação: versão bild/config/instância de ferro.
Circuito A/B: Um teste paralelo em um ambiente idêntico; ou ABAB/Latin Square para reduzir o impacto da deriva.
Número de repetições: ≥ 10 curtas + 3 longas para configuração para avaliações sustentáveis.
Estatísticas: mediana, MAD, espaçamento de confiança; Testes não-aramétricos (Mann-Whitney) para as distribuições de cauda.
DoE (mínimo): Altere uma variável por vez (OVAT) ou um fator factual para 2-3 fatores (por exemplo, perfil TLS x HTTP x núcleo).

Controle de variáveis e ruídos

CPU governor: `performance`; desativar «power save».
Turbo/Throttling: Monitoramento de frequências, temperaturas e trottling (caso contrário, aquecimento dará falsos ganhos).
NUMA/Hyper-Threading: fixe o IRQ e os processos ('taskset/numactl'), mede a localidade da memória.
C-states/IRQ balance: capte as configurações; para testes de rede - pin IRQ para núcleos específicos.
Processos de fundo: fio limpo, desligar cron/backup/antivirus/updatedb.
Rede: caminhos estáveis, MTU/ECN/AQM fixos, falta de flatter do canal.
Dados: conjunto idêntico, cardinalite e distribuição.
Cash: separe os modos «frio» (primeira passagem) e «quente» (novo), marce claramente.

Classes de benchmark

1) Micro-benchmark (função/algoritmo)

O objetivo é medir um código/algoritmo específico.
Ferramentas: quadros embutidos (Go 'testing. B`, JMH, pytest-benchmark).
Regras: aquecimento de JIT, milissegundos → nanossegundos; Isolamento GC; seed fixo.

2) Meso-benchmark (componente/serviço)

Servidor HTTP, dinheiro, corretor, BD em um nodo.
Ferramentas: wrk/wrk2, k6 (open model), vegeta, ghz (gRPC), fio, sysbench, iperf3.
Regras: limites de conexão/arquivo, pool; relatório de CPU/IRQ/GC.

3) Macro-benchmark (e2e/caminho de consulta)

Caminho completo CDN/edge proxy serviço BD/dinheiro resposta.
Ferramentas: k6/Locust/Gatling + RUM/OTEL Training; uma mistura realista de rotas.
Regras: mais perto da realidade (dados «sujos», lajes de sistemas externos), com cuidado com retraias.

Conjunto de métricas por camadas

Modelos de teste e comando

bash iperf3 -s # server iperf3 -c <host> -P 8 -t 60 # parallel, stable bandwidth

bash wrk2 -t8 -c512 -d5m -R 20000 https://api. example. com/endpoint \
--latency --timeout 2s

javascript export const options = {
scenarios: { open: { executor: 'constant-arrival-rate', rate: 1000, timeUnit: '1s',
duration: '10m', preAllocatedVUs: 2000 } },
thresholds: { http_req_failed: ['rate<0. 3%'], http_req_duration: ['p(95)<250'] }
};

bash fio --name=randread --rw=randread --bs=4k --iodepth=64 --numjobs=4 \
--size=4G --runtime=120 --group_reporting --filename=/data/testfile

bash sysbench oltp_read_write --table-size=1000000 --threads=64 \
--pgsql-host=... --pgsql-user=... --pgsql-password=... prepare sysbench oltp_read_write --time=600 --threads=64 run

bash perf stat -e cycles,instructions,cache-misses,L1-dcache-load-misses \
-- <your_binary> --bench

Estatísticas e validade

Repetições: pelo menos 10 upons, excluir outliers (robástico: mediana/MAD).
Espaçamento de confiança: 45% CI para p95/p99 e média.
Efeito-tamanho: alteração relativa e CI (por exemplo, 12% [9%; 15%]).
Valor prático: uma redução de 10% do p95 com um preço de + 30% de CPU - vale a pena?
Gráficos: violin/ECDF para distribuição, curvas de saturação (RPS→latency).

Perfilar e localizar espaço restrito

CPU: `perf`, `async-profiler`, eBPF/pyroscope; flamegraph antes e depois.
Alloc/GC: perfis de runtime (Go pprof/Java JBR).
I/O: `iostat`, `blktrace`, `fio --lat_percentiles=1`.
Сеть: `ss -s`, `ethtool -S`, `dropwatch`, `tc -s qdisc`.
БД: `EXPLAIN (ANALYZE, BUFFERS)`, pg_stat_statements, slowlog.
Chave Top, TTL, evision causa.

Relatórios e artefatos

• git SHA bild, bandeiras de compilação/otimização.
• Configs de núcleo/rede (sysctl), versões de driver/NIC/firmware.
• Topologia (vCPU/NUMA/HT), governor, temperatura/frequência.
• Dados: tamanho, cardinalite, distribuição.
• O que publicar: tabelas p50/p95/p99, erro/segundo, throughput, recursos (CPU/RAM/IO), CI.
• Artefactos: ário, gráficos, flamegraph, JSON cru/CSV resultados, protocolo de ambiente.

Comparações honestas (fair benchmarking)

Limitadores idênticos (conn pool, keepalive, TLS cadeias, OCSP stapling).
Timeouts/retrai alinhados e a versão HTTP (h2/h3).
Equilíbrio de temperatura: aquecimento para equilíbrio (sem efeito turbo-bust).
Caciques justos, ambos «frios» ou «quentes».
Simetria de rede: trajetos idênticos/MTU/ECN/AQM.
Orçamento de tempo: DNS/TLS/connect - Contar claramente ou excluir da mesma forma.

Anti-pattern

Um teste → «conclusão».
Mistura de modos (parte frios, parte quentes) na mesma série.
Um modelo fechado, em vez de aberto para a carga de Internet, → uma falsa «sustentabilidade».
Retraias não contabilizadas «RPS cresce» ao custo de duplicações e em cascata 5xx.
Comparação em diferentes glândulos/núcleos/energia.
A falta de perfilação → a otimização às cegas.
Jogo com GC/heap sem análise de perfis → regressão de caudas.

Receitas práticas

1. Bloquear ambiente (script 'eng _ capture. sh`).

2. Aquecer (5-10 min), fixar frequência/temperatura.

3. Realizar N repetições de curtas + 1 de longa duração.

4. Retirar perfis (CPU/alloc/IO) no pico.

5. Contar a CI/gráficos, recolher artefatos.

6. Decisão: aceitar/rejeitar hipótese, formar next steps.

• Degraus RPS (10% do passo) → registramos p95/erros → encontramos «joelho».
• Fazemos um cronograma e , vemos a fronteira e o custo de mais%.

Especificidades para iGaming/Fintech

Custo de milissegundos: classifique as melhorias em $ efeito (conversão/saída/limites PSP).
Picos (jogos/torneios): benchmarks spike + plateau com aquecimento TLS/CDN/dinheiro.
Pagamentos/PSP: Mede end-to-end com limites sandbox, idempotidade e resposta à degradação; Fixe o Time-to-Wallet com métricas proxy.
Filtros antifrod/bot: inclua um perfil de regras no macro-bench (falso-positivo-rate, latency suplement).
Líderes/jackpots: teste chaves quentes/classificação, bloqueios, atômica.

Folha de cheque do benchmarking

• Hipótese/métricas/critério de sucesso.
• Controle de variáveis (alimentação/NUMA/IRQ/rede/dinheiro).
• Plano de testes (réplicas, duração, aquecimento).
• Separação de modo frio/quente.
• Perfilação habilitada (CPU/alloc/IO/BD).
• Estatísticas: CI, testes de importância, gráficos.
• Artefatos e arquivos repro no repositório (IaC para estande).
• Relatório com «custo de melhoria» e recomendações.
• Retuíte após otimização (regressão perf).

Mini-relatório (modelo)

Objetivo: reduzir p95 API em 15% sem crescimento CPU> 10%.
Método: A/B, k6 open-model 1k rps, 10 x 3 progons, warm cache.
Total: p95 - 12% [- 9%; 15%], CPU + 6%, 5xx inalterado.
Flamegraph: ↓ o JSON é uma seriada (- 30% CPU), a restrição mudou-se para o banco de dados.
Decisão: aceitar otimização; o próximo passo é batucar as solicitações do banco de dados.
Artefactos, gráficos, perfis, configs, JSON cru.

Resultado

Um bom benchmarking é uma metodologia rigorosa + comparações justas + validade estatística + perfilagem + reprodutividade. Apresente-se a hipóteses, controle do ambiente, conta os intervalos de confiança, publica artefatos e tome decisões sobre o custo da melhoria. Assim você não terá um número bonito na apresentação, mas um aumento real da velocidade e previsibilidade da plataforma.