"O teste deu latência de 150ms." Ok, mas o que isso significa? É bom? É ruim? Comparado a quê? Números de testes de performance sem contexto e interpretação são apenas dígitos. Este artigo ensina a extrair significado real dos resultados.
Dados não são insights. Interpretação transforma dados em conhecimento.
O Problema dos Números Brutos
Números sem contexto
Resultado do teste:
- Latência p95: 250ms
- Throughput: 1500 req/s
- Error rate: 0.5%
Perguntas que números não respondem:
- Isso atende os requisitos?
- Comparado ao baseline, melhorou ou piorou?
- Quais endpoints contribuíram?
- Foi estável ou variou durante o teste?
- O ambiente de teste era representativo?
O risco de interpretação superficial
Cenário:
"Latência média: 100ms. Teste passou!"
Realidade:
- p50: 50ms
- p95: 200ms
- p99: 2000ms
- Max: 30s
Conclusão real:
Média esconde que 1% dos usuários tem
experiência terrível (>2s)
Framework de Interpretação
1. Contexto primeiro
Antes de olhar números, pergunte:
- Qual era o objetivo do teste?
- Qual a carga aplicada vs esperada?
- Qual ambiente foi usado?
- Quanto tempo durou?
- Havia dados realistas?
2. Comparação com baseline
Resultado isolado:
p95 = 200ms
Com baseline:
Baseline: p95 = 180ms
Teste: p95 = 200ms
Δ: +11%
Interpretação:
Regressão de 11% - investiga ou aceita?
3. Distribuição, não média
Sempre usar:
- p50 (mediana) - experiência típica
- p95 - maioria dos usuários
- p99 - pior caso comum
- Max - outliers
Nunca confiar apenas em:
- Média (esconde variância)
- Min (irrelevante)
4. Tendência ao longo do tempo
Latência constante:
───────────────────
Bom: Sistema estável
Latência crescente:
╱╱╱╱╱╱╱╱╱╱╱╱╱╱╱╱╱╱╱
Problema: Memory leak? Queue buildup?
Latência com picos:
─╲─╱─╲─╱─╲─╱─╲─╱─
Investiga: GC? Background jobs? External API?
Analisando por Camada
Análise de endpoint
Resultado agregado:
p95 = 300ms
Por endpoint:
GET /api/products: p95 = 100ms ✓
GET /api/product/:id: p95 = 150ms ✓
POST /api/checkout: p95 = 2s ✗ ← Problema!
Insight:
Checkout precisa de atenção específica
Análise de componente
Resultado end-to-end:
p95 = 500ms
Breakdown:
API Gateway: 50ms (10%)
Auth Service: 80ms (16%)
Order Service: 120ms (24%)
DB Query: 200ms (40%) ← Maior contribuidor
Serialization: 50ms (10%)
Insight:
Otimização do DB terá maior impacto
Análise de recurso
Métricas de performance OK, mas:
CPU: 95%
Memory: 7.8GB / 8GB
DB Connections: 95 / 100
Interpretação:
Sistema funcionando no limite
Sem headroom para crescimento
Próximo pico pode causar falha
Identificando Padrões
Correlações importantes
Latência sobe quando:
- CPU > 80%? → CPU-bound
- Memory > 90%? → GC stress
- Connections > 80%? → Connection starvation
- Throughput aumenta? → Saturação
Erros aparecem quando:
- Timeout? → Dependência lenta
- 5xx? → Falha de aplicação
- Connection refused? → Pool exhausted
Red flags
Atenção para:
- Variância alta (p99/p50 > 10x)
- Erros crescentes ao longo do tempo
- Latência que não estabiliza
- Throughput que cai durante teste
- Recursos em 100% (qualquer um)
False positives
Cuidado com:
- Primeiro minuto (warm-up)
- Picos únicos (podem ser outliers)
- Ambiente não-representativo
- Cache muito quente ou frio
- Dados de teste não-realistas
Relatório de Resultados
Estrutura recomendada
# Relatório de Teste - [Nome]
## 1. Sumário Executivo
- Status: PASSOU / FALHOU / COM RESSALVAS
- Capacidade validada: X req/s
- Principais findings: [bullets]
- Ações recomendadas: [bullets]
## 2. Contexto do Teste
- Data: [quando]
- Ambiente: [onde]
- Carga: [quanto]
- Duração: [tempo]
- Cenário: [descrição]
## 3. Resultados vs Critérios
| Métrica | Critério | Resultado | Status |
|---------|----------|-----------|--------|
| p95 latência | < 500ms | 380ms | ✓ |
| Error rate | < 1% | 0.3% | ✓ |
| Throughput | > 1000 req/s | 1250 | ✓ |
## 4. Análise Detalhada
### Por Endpoint
[Tabela com breakdown]
### Por Componente
[Tabela com breakdown]
### Tendência Temporal
[Gráfico e observações]
## 5. Observações e Riscos
- [Observação 1]
- [Risco identificado]
## 6. Recomendações
- [Ação 1 - prioridade alta]
- [Ação 2 - prioridade média]
## 7. Próximos Passos
- [O que fazer com esses resultados]
Visualizações essenciais
Gráficos que ajudam:
1. Latência ao longo do tempo:
- Mostra estabilidade
- Revela tendências
2. Distribuição de latência (histograma):
- Mostra dispersão
- Identifica multimodalidade
3. Throughput vs Latência:
- Mostra ponto de saturação
- Identifica correlação
4. Recursos vs Tempo:
- CPU, Memory, Connections
- Correlaciona com performance
Interpretações Comuns
"O teste passou"
Pergunta de follow-up:
- Com qual margem?
- Qual o headroom?
- Próximo do limite?
Exemplo:
Critério: p95 < 500ms
Resultado: p95 = 480ms
Tecnicamente passou, mas:
- Margem de 4%
- Qualquer degradação = falha
- Recomendação: otimizar antes de produção
"O teste falhou"
Não pare na falha:
- Onde falhou primeiro?
- Quanto faltou para passar?
- Foi consistente ou intermitente?
Exemplo:
Critério: p95 < 500ms
Resultado: p95 = 650ms
Análise:
- Falhou por 30%
- Gargalo: DB (contribui 400ms)
- Otimizar DB pode resolver
"Resultados inconsistentes"
Variância alta indica:
- Ambiente instável
- GC não-determinístico
- Dependências externas
- Carga não-uniforme
Ação:
- Rodar mais vezes
- Aumentar duração
- Isolar variáveis
- Investigar picos
Anti-Patterns de Interpretação
1. Cherry-picking
❌ "O melhor resultado foi 100ms"
✅ "Mediana foi 150ms, melhor foi 100ms, pior foi 2s"
2. Ignorar warm-up
❌ Incluir primeiros 2 minutos na análise
✅ Descartar warm-up, analisar steady-state
3. Comparar incomparáveis
❌ "Prod tem 200ms, teste tem 300ms, regressão de 50%"
(Se ambiente de teste é diferente)
✅ "Comparando mesmo ambiente, antes/depois da mudança"
4. Média como verdade
❌ "Média de 100ms, excelente!"
(Quando p99 é 5s)
✅ "p50=80ms, p95=200ms, p99=5s - outliers são problema"
Conclusão
Interpretar resultados corretamente requer:
- Contexto - comparar com baseline e requisitos
- Distribuição - percentis, não médias
- Tendência - comportamento ao longo do tempo
- Breakdown - por endpoint e componente
- Correlação - performance vs recursos
Números são o começo, não o fim. O valor está no insight que você extrai.
O teste gera dados. Você gera conhecimento.
Este artigo faz parte da série sobre a metodologia OCTOPUS de Performance Engineering.