Visão geral

No ano passado, a maior venda do BoxOffice caiu às 10:02. O time tinha feito teste de carga: 200 usuários virtuais contra o staging, p95 de 180 ms, "tudo verde". No post-mortem, encontraram cinco problemas nesse teste. O staging tinha um décimo dos dados da produção, então toda consulta acertava um cache quente. Os usuários virtuais esperavam cada resposta antes de enviar a próxima requisição, então, quando o sistema ficou lento, o teste educadamente ficou lento junto e nunca viu a fila que os fãs reais formaram. O teste durou dez minutos e nunca chegou ao ponto em que o pool de conexões do banco se esgotava. Ninguém tinha escrito o que significava "bom o suficiente" antes de rodá-lo. E o relatório mostrava médias.

Engenharia de desempenho é a disciplina que evita esse post-mortem. Não é "rodar uma ferramenta e olhar um gráfico": é um método — declarar o objetivo, modelar a carga de trabalho, gerar carga que se comporte como usuários reais, medir o que os usuários sentem, encontrar o único recurso que limita o sistema, corrigi-lo e medir de novo. Esta aula ensina o método e as ferramentas, usando a venda relâmpago do BoxOffice como caso de teste.

Roteiro

1. Esta visão geral — o vocabulário, a curva vazão–latência e seu joelho, e o ciclo de engenharia de desempenho.
2. Metodologia — anti-métodos, caracterização da carga, os métodos USE e RED, ambientes de teste, dados de teste e aquecimento.
3. Testes de carga — os seis tipos de teste em k6, modelos aberto vs fechado, thresholds como SLOs, omissão coordenada, caos sob carga e os perfis do playground.
4. Encontrando gargalos — leitura dos resultados, profiling e flame graphs, gargalos de banco de dados, dimensionamento de pools.
5. Planejamento de capacidade — Lei de Little e folga, atraso do autoscaling, um modelo de capacidade para a venda e orçamentos de desempenho na CI.
6. Quiz — teste seu entendimento.

Slides

Clique nos slides e use ← → para navegar; F abre em tela cheia e P abre a visão do apresentador, com as notas. Abrir os slides em uma nova aba

O vocabulário de desempenho

Palavras precisas evitam a maioria das discussões sobre desempenho. A aula de Estimativas as apresentou; aqui elas viram alvos de medição.

Três relações valem para qualquer sistema estável e merecem ser memorizadas:

• Lei de Little: \(N = X \times R\) — a concorrência é igual à vazão vezes o tempo de resposta¹. A 1 800 reservas/s e 0,12 s cada, há em média 216 reservas em andamento: é de quantas threads, conexões ou slots assíncronos o caminho precisa.
• Lei da utilização: \(U = X \times S\) — um banco que gasta 0,4 ms de CPU por consulta (por núcleo) a 2 000 consultas/s em um núcleo está 80 % ocupado.
• Tempo de resposta = tempo de serviço + tempo de espera: otimizar código encurta o tempo de serviço; adicionar capacidade ou reduzir a carga encurta a espera. Perto da saturação, a espera domina.

A curva vazão–latência e seu joelho

Todo sistema, de uma thread a um data center, mostra a mesma forma quando você aumenta a carga. O gráfico da esquerda modela um pod de inventory com 8 threads de trabalho e 20 ms de tempo médio de serviço — capacidade de 400 requisições por segundo — como uma fila M/M/8. O da direita usa a Lei Universal de Escalabilidade (USL, Universal Scalability Law), que adiciona contenção (σ, esperar por recursos compartilhados) e coerência (κ, o custo de manter o estado compartilhado consistente) à escala linear ideal²:

Leia os dois gráficos juntos:

1. A região plana. Com carga baixa, a latência é só o tempo de serviço. Dobrar a carga quase não a muda. A maioria dos sistemas passa a maior parte da vida aqui, e é por isso que parecem rápidos.
2. O joelho. Acima de cerca de 70–80 % de utilização, as requisições começam a encontrar todos os servidores ocupados e entram na fila. A latência — e o p99 primeiro — se curva para cima. O joelho é a capacidade útil do sistema: a maior vazão em que o SLO de latência ainda é cumprido.
3. Saturação. Quando a carga oferecida se aproxima da capacidade, as filas crescem sem limite; a latência fica vertical e os timeouts viram erros. A vazão para de crescer.
4. Escala retrógrada. Com custos de contenção e coerência, adicionar mais concorrência depois do pico reduz a vazão — threads brigam por locks, caches se invalidam, conexões expiram e são refeitas. Um sistema empurrado além do pico pode vender menos ingressos por segundo do que um mantido logo abaixo dele, que é o argumento central para controle de admissão e salas de espera.

#!/usr/bin/env bash
# Lab 2: run load.js once per arrival rate and save one k6 summary per run.
#   bash scripts/sweep.sh 25 50 100 150 200 300 400
# Then:  uv run scripts/summarize.py results/lab2/rate-*.json
set -euo pipefail
OUT=${OUT:-results/lab2}
DURATION=${DURATION:-1m}
mkdir -p "$OUT"
echo ">>> warm-up: 30 s at RATE=$1 (not recorded)"
k6 run -q -e RATE="$1" -e DURATION=30s load/load.js > /dev/null || true
for rate in "$@"; do
  echo ">>> RATE=$rate req/s for $DURATION"
  # || true: a run that crosses a threshold still produces a summary; keep sweeping
  k6 run -q -e RATE="$rate" -e DURATION="$DURATION" \
     --summary-export "$OUT/rate-$rate.json" load/load.js > /dev/null || true
  sleep 10   # let queues drain before the next step
done

Experimente: este cenário do playground é o sistema mais simples possível — cliente → servidor de aplicação → banco SQL — rodando o perfil breakpoint, que aumenta a taxa de chegada passo a passo até algo quebrar. Pressione Run e observe três números juntos: vazão, latência p99 e a utilização de cada componente. Anote a taxa em que o p99 começa a se curvar (o joelho) e qual componente chega a 100 % primeiro (o gargalo). Depois dê mais capacidade a esse componente e rode de novo: o joelho se move, e qual componente vira o novo gargalo?

Abra o playground completo para adicionar um cache ou réplicas de leitura e ver como a curva muda.

O ciclo de engenharia de desempenho

Trabalho de desempenho é um ciclo científico, não um evento único antes do lançamento³:

flowchart LR
    slo["1. Objetivos<br/>SLOs por endpoint,<br/>pico esperado"] --> model["2. Modelo de carga<br/>mix, padrão de chegada,<br/>dados"]
    model --> test["3. Teste<br/>cenário k6 em um<br/>ambiente parecido com produção"]
    test --> analyze["4. Análise<br/>curva, USE, RED,<br/>perfis"]
    analyze --> fix["5. Mude UMA coisa<br/>(código, config,<br/>capacidade)"]
    fix --> test
    analyze --> ship["6. Publique + orçamento na CI<br/>monitore em produção"]
    ship --> slo

• Objetivos primeiro. "Rápido" não é um requisito. "POST /holds: p99 < 300 ms e erros < 0,1 % a 4 500 req/s" é. Sem isso, nenhum teste pode passar ou falhar.
• Mude uma coisa de cada vez e rode o mesmo teste de novo — senão você não consegue atribuir a melhoria.
• A produção fecha o ciclo. O tráfego real é o melhor modelo de carga: métricas e traces de produção alimentam o próximo teste, e o orçamento de desempenho na CI impede que regressões voltem.

O mapa de conceitos de desempenho

A engenharia de desempenho não acrescenta caixas novas à paleta: ela mede as que você já tem. O mapa liga cada componente da paleta (verde) aos conceitos usados para carregá-lo, observá-lo e dimensioná-lo (azul):

flowchart LR
    client["client · mobile<br/>(k6 generates them)"]:::comp --> edge["apigw · lb"]:::comp
    edge --> app["app"]:::comp
    app --> sql["sql"]:::comp
    app --> cache["cache"]:::comp
    queue["queue<br/>(waiting room)"]:::comp --> app
    obs["metrics · tracing"]:::comp -.- app
    client -.- c1["open vs closed model,<br/>6 test types, thresholds"]:::tech
    app -.- c2["Little's Law, the knee,<br/>USL"]:::tech
    sql -.- c3["EXPLAIN ANALYZE, hot rows,<br/>pool sizing"]:::tech
    cache -.- c4["warm-up, cold cache,<br/>hit ratio"]:::tech
    obs -.- c5["USE, RED,<br/>flame graphs"]:::tech
    queue -.- c6["headroom, autoscaling lag,<br/>admission control"]:::tech
    classDef comp fill:#1e9e5a22,stroke:#1e9e5a
    classDef tech fill:#2f6fed22,stroke:#2f6fed

Relacionados

• Hands-on: 2. Medir primeiro (k6 smoke/load/stress no catalog, encontrar o joelho, verificação da Lei de Little), 6. Dados em escala (EXPLAIN ANALYZE, índices, PgBouncer), 9. Resiliência e caos (k6 sob falhas do Toxiproxy) e 11. Entrega (gate de orçamento de desempenho com k6 na CI).
• Exercício: Relatório de teste de carga; projeto: Campanha de testes de carga e Game day.
• Aulas: Estimativas — filas e percentis, Observabilidade, Confiabilidade — engenharia do caos.
• Estudo de caso: Ticketing (venda relâmpago do BoxOffice); ferramentas: Referência — ferramentas.

Pontos-chave

O que quebra em seguida

A engenharia de desempenho prova este projeto para esta carga: um sistema de ingressos, uma venda, uma mistura de cerca de 80 % de leituras e 20 % de reservas e pedidos, um joelho medido nos próprios pods do BoxOffice. O método — modelo de carga, testes de modelo aberto, o joelho, a folga, um orçamento na CI — vale para qualquer sistema; os números e as caixas, não. Um feed de notícias espalha cada post para milhões de seguidores, um chat mantém milhões de conexões abertas por horas, um app de corridas grava a posição de cada motorista a cada poucos segundos: números diferentes pedem blocos diferentes. Reconhecer quais blocos dos quinze capítulos anteriores um sistema novo precisa, e qual número pede cada um, é a aula 16 — Estudos de caso.