Metodologia

"O inventory está lento no teste da pré-venda." Em dez minutos, o canal do time tem quatro propostas: colocar um cache Redis, mudar para uma instância de banco maior, adicionar mais pods, reescrever o caminho quente em Go. Cada uma custa dias ou dólares; no máximo uma ataca a causa real; e ninguém olhou uma única métrica ainda. Uma metodologia é o que substitui esse chute: uma forma sistemática de ir de um sintoma ao recurso limitante, e de lá à única mudança que importa.

Anti-métodos: como não fazer

Brendan Gregg cataloga as abordagens que parecem produtivas e não são¹:

A alternativa é o método científico⁵: fazer uma pergunta ("por que o p99 de POST /holds é 2 s a 1 500 req/s?"), formular uma hipótese ("o pool de conexões está esgotado"), fazer uma previsão ("pendentes no pool > 0 e tempo de espera ≈ o aumento de latência"), testá-la com uma medição e só então mudar algo — uma coisa — e medir de novo.

Caracterização da carga: que carga, exatamente?

Um teste é tão bom quanto seu modelo da carga. A caracterização da carga responde a quatro perguntas¹:

Dos logs a um modelo de carga

Os logs de acesso de produção (ou as métricas do gateway) são a fonte da verdade. Uma consulta sobre uma venda passada dá o mix e a taxa de chegada:

SELECT route,
       count(*)                                         AS requests,
       round(100.0 * count(*) / sum(count(*)) OVER (), 1) AS pct,
       max(per_second)                                  AS peak_rps
FROM (
  SELECT route, date_trunc('second', ts) AS sec, count(*) OVER (PARTITION BY route, date_trunc('second', ts)) AS per_second
  FROM gateway_access_log
  WHERE ts BETWEEN '2026-09-12 09:55' AND '2026-09-12 10:30'
) t
GROUP BY route
ORDER BY requests DESC;

O resultado vira o modelo de carga que todos os testes desta aula reutilizam (os números são premissas ilustrativas para uma venda de estádio):

Três propriedades das cargas reais são perdidas rotineiramente nos testes e precisam ser modeladas de propósito:

• Assimetria (skew). As requisições não são uniformes sobre os dados. Durante uma venda, um evento recebe quase todo o tráfego, e os melhores setores recebem a maioria das reservas — o clássico problema de chave quente / linha quente. A popularidade costuma ser modelada com uma distribuição de Zipf.
• Sessões e think time. Um fã olha o mapa de assentos por alguns segundos antes de reservar. O think time (a pausa entre as requisições de um usuário) molda a concorrência: com a mesma taxa de chegada, think times mais longos significam mais sessões simultâneas (Lei de Little de novo).
• Chegadas sincronizadas. Vendas reais não são uma rampa suave: centenas de milhares de clientes atualizam a página às 10:00:00. Um teste que sobe a carga em 10 minutos perde o segundo mais perigoso do dia.

O método USE: um checklist para cada recurso

O método USE diz: para cada recurso, verifique Utilização, Saturação e Erros². Sua força é a completude — ele faz você olhar recursos que esqueceria — e a rapidez: alguns minutos de verificação estreitam a busca para um recurso.

• Utilização — quão ocupado o recurso está (porcentagem do tempo ou da capacidade).
• Saturação — quanto trabalho extra está na fila esperando por ele.
• Erros — eventos de erro (alocações que falham, pacotes descartados, timeouts).

Recursos não são só hardware. Em um serviço Java, os recursos de software — pools, locks, filas — saturam com mais frequência do que a CPU:

Um passo a passo: por que POST /holds está lento?

Durante um teste de pré-venda a 1 500 reservas/s, o p99 de POST /holds é 2,1 s (SLO: 300 ms). Seguindo o USE, de cima para baixo:

flowchart TD
    s["Sintoma: p99 de POST /holds = 2,1 s a 1 500 req/s"] --> cpu{"CPU do inventory?"}
    cpu -->|"U 45 %, fila de execução baixa,<br/>sem throttling"| mem{"Memória / GC?"}
    mem -->|"GC < 2 % do tempo"| tp{"Threads do Tomcat?"}
    tp -->|"200 / 200 ocupadas — saturado,<br/>mas ocupadas fazendo o quê?"| pool{"Pool Hikari?"}
    pool -->|"10 / 10 ativas,<br/>180 threads pendentes"| db{"PostgreSQL?"}
    db -->|"CPU 35 %, mas sessões em<br/>wait_event = Lock: tuple"| root["Gargalo: contenção de locks de linha em assentos quentes,<br/>mantidos durante toda a transação"]

1. CPU do inventory: 45 % de utilização, fila de execução curta, sem throttling. Não é o gargalo — adicionar pods não ajudaria.
2. Memória/GC: o GC usa menos de 2 % do tempo. Tudo bem.
3. Threads do Tomcat: todas as 200 ocupadas. Saturado — mas threads são um recurso sintoma: estão ocupadas esperando alguma coisa.
4. Pool de conexões: 10 de 10 conexões ativas, 180 threads pendentes. Toda reserva espera uma conexão: pela Lei de Little, 180 esperando / 1 500 por segundo ≈ 120 ms de espera no pool em média, e muito mais na cauda.
5. PostgreSQL: CPU só a 35 % — então uma instância maior também não ajudaria. Mas o pg_stat_activity mostra a maioria das sessões em wait_event = Lock: tuple: transações esperam por locks de linha nos mesmos poucos assentos quentes, e cada transação mantém seu lock enquanto também chama o serviço de preços.

O gargalo é contenção de locks, amplificada por transações longas. Das quatro propostas da introdução, nenhuma resolveria: um cache não ajuda escritas, um banco maior já tem CPU ociosa, mais pods adicionariam mais gente esperando, e Go esperaria nos mesmos locks. As correções que funcionam — transações mais curtas (chamar o serviço de preços antes do BEGIN), SELECT … FOR UPDATE SKIP LOCKED para entregar aos fãs assentos livres diferentes e uma sala de espera para limitar as reservas concorrentes — são discutidas em Encontrando gargalos e Bancos de dados — transações.

SELECT wait_event_type, wait_event, state, count(*)
FROM pg_stat_activity
WHERE datname = 'boxoffice'
GROUP BY 1, 2, 3
ORDER BY count(*) DESC;

#!/usr/bin/env bash
# Lab 2: print, once per second, how many requests are INSIDE the service right now.
#   bash scripts/watch-metrics.sh http://localhost:8082
URL=${1:-http://localhost:8082}
metric() {   # metric <name>: current value of an actuator metric
  curl -s "$URL/actuator/metrics/$1" | jq -r '.measurements[0].value // "?"'
}
printf '%-8s %13s %10s %11s\n' time busy_threads db_active db_pending
while true; do
  printf '%-8s %13s %10s %11s\n' "$(date +%T)" \
    "$(metric tomcat.threads.busy)" \
    "$(metric hikaricp.connections.active)" \
    "$(metric hikaricp.connections.pending)"
  sleep 1
done

RED e os sinais de ouro: a visão do serviço

O USE olha os recursos por dentro. O método RED olha cada serviço por fora, do jeito que os usuários o experimentam³:

• Rate (taxa) — requisições por segundo;
• Errors (erros) — requisições com falha por segundo (ou como fração);
• Duration (duração) — a distribuição de latência (histogramas → percentis).

Os quatro sinais de ouro do Google — latência, tráfego, erros, saturação — são a mesma ideia mais a saturação⁴. Use os dois juntos: o RED diz qual serviço está infeliz; o USE diz qual recurso dentro dele é a causa. Em um teste de carga, as métricas RED de cada serviço são os thresholds; as métricas USE são o que você inspeciona quando um threshold falha. A aula de Observabilidade mostra como coletar ambos com OpenTelemetry.

Paridade do ambiente de teste

Um teste de carga mede o ambiente em que roda. Cada diferença em relação à produção é um motivo para o resultado não se transferir:

Como a infraestrutura é código (Entrega), a opção mais confiável é um ambiente de desempenho efêmero: criado a partir dos mesmos módulos Terraform/OpenTofu e manifests da produção durante a campanha de testes, carregado com um conjunto de dados sintéticos do tamanho da produção e destruído depois.

catalog:
  build: ../../services/catalog
  environment:
    DB_HOST: db
    DB_PORT: 5432
    DB_NAME: boxoffice
    DB_USER: boxoffice
    DB_PASSWORD: boxoffice
    REDIS_HOST: redis
    REDIS_PORT: 6379
  ports:
    - "8082:8082"
  depends_on:
    db:
      condition: service_healthy
    redis:
      condition: service_healthy
  deploy:
    resources:
      limits:
        cpus: "1.0"          # the same limit as in docker-compose.yaml: budgets are per replica
        memory: 768M
  healthcheck:
    test: ["CMD-SHELL", "wget -qO- http://localhost:8082/actuator/health/readiness || exit 1"]
    interval: 5s
    timeout: 3s
    start_period: 60s
    retries: 30

Dados de teste

• Volume: mesma ordem de grandeza da produção — os tamanhos das tabelas determinam a profundidade dos índices, a escolha dos planos e se o conjunto de trabalho cabe na memória.
• Distribuição: reproduza a assimetria (um evento quente, setores populares) — senão você perde a contenção de locks e as partições quentes, e superestima os misses de cache na cauda longa.
• Unicidade: se todo usuário virtual entra com a mesma conta ou reserva o mesmo assento, você testa um ponto quente artificial; se toda requisição pede um evento aleatório diferente, você testa um cache frio artificial. Parametrize a partir de arquivos de dados realistas.
• Reset de estado: reservas e pedidos mudam os dados. Restaure um snapshot do banco antes de cada execução para que as execuções sejam comparáveis.
• Privacidade: nunca copie dados pessoais de produção para um ambiente de teste; gere dados sintéticos com a mesma forma estatística.

import { SharedArray } from 'k6/data';

const users  = new SharedArray('users',  () => JSON.parse(open('./data/users.json')));    // 50 000 synthetic fans
const events = new SharedArray('events', () => JSON.parse(open('./data/events.json')));   // sorted by popularity

// Zipf-like choice: low indexes (popular events) are chosen much more often
export function pickEvent() {
  const u = Math.random();
  return events[Math.floor(events.length * Math.pow(u, 3))];
}

export function pickUser() {
  return users[Math.floor(Math.random() * users.length)];
}

Aquecimento: meça o regime permanente — e teste o frio

Logo depois de um deploy, um serviço JVM é mais lento do que será em cinco minutos: classes estão carregando, o compilador JIT ainda não compilou os métodos quentes, os pools de conexão estão enchendo, o Redis e o cache de buffers do PostgreSQL estão frios e o autoscaler está no mínimo. Medir esse período mistura duas perguntas diferentes.

• Testes de regime permanente (load, soak, breakpoint) devem aquecer primeiro e excluir o aquecimento dos thresholds.
• Testes de partida a frio medem deliberadamente o sistema frio, porque a produção também tem momentos frios: um deploy durante o tráfego, um cache esvaziado, um failover para uma réplica fria, novos pods adicionados pelo autoscaler durante o pico.

export const options = {
  scenarios: {
    warmup: {
      executor: 'constant-arrival-rate', rate: 200, timeUnit: '1s',
      duration: '3m', preAllocatedVUs: 100, exec: 'browse',
    },
    measure: {
      executor: 'constant-arrival-rate', rate: 1000, timeUnit: '1s',
      duration: '15m', preAllocatedVUs: 500, maxVUs: 2000,
      startTime: '3m', exec: 'browse',
    },
  },
  thresholds: {
    // only the 'measure' scenario counts towards pass/fail
    'http_req_duration{scenario:measure}': ['p(99)<300'],
    'http_req_failed{scenario:measure}': ['rate<0.001'],
  },
};

Ruído e repetibilidade

Ambientes de nuvem são ruidosos: vizinhos compartilham hosts, redes variam, autoscalers tomam caminhos diferentes. Uma execução é uma anedota.

• Repita cada configuração pelo menos três vezes e reporte a mediana e a dispersão; uma diferença menor que a dispersão entre execuções não é um resultado.
• Verifique o gerador de carga: CPU abaixo de ~70 %, rede não saturada, VUs suficientes alocados (o k6 avisa quando um cenário de taxa de chegada fica sem VUs: dropped_iterations). Para testes grandes, rode o k6 distribuído (k6-operator no Kubernetes ou um serviço na nuvem).
• Mesmas condições: mesmo snapshot de dados, mesma janela de horário, mesmas versões; registre-as no relatório.
• Longo o suficiente: um teste de 2 minutos não revela um vazamento de conexões, o crescimento de arquivos de log ou um vazamento de memória — esse é o trabalho do teste soak.

Como se conecta

flowchart LR
    SYM["symptom:<br/>POST /holds is slow"] --> RED["RED per service<br/>→ Observability signals"]
    RED --> USE["USE per resource: CPU,<br/>thread pool, connection pool, locks"]
    USE --> BOT["the saturated resource"]
    BOT --> FIX["change ONE thing<br/>→ Bottlenecks"]
    LOGS["gateway access logs<br/>in the warehouse"] --> WL["workload model:<br/>mix, arrival rate"]
    WL --> TEST["load test<br/>→ Load testing"]
    ENV["environment parity,<br/>test data, warm-up"] --> TEST
    NOISE["repeat runs,<br/>check the load generator"] --> TEST
    TEST --> SYM

Componentes da paleta: metrics e tracing (RED para serviços, USE para recursos) · logs, apigw e dwh (logs de acesso transformados em modelo de carga) · app (pools de threads, CPU) · sql (pool de conexões, locks) · cache (quente vs frio) · waf (bots que não fazem parte da carga). Cenários: monolith (perfil breakpoint), observability-stack. Continua em: Observabilidade — sinais, Testes de carga, Encontrando gargalos, Bancos de dados — transações, Cloud-native — entrega (ambientes de desempenho efêmeros).