"Melhoramos a performance em 30%". Comparado a quê? Se você não sabe responder essa pergunta com dados, você não sabe se realmente melhorou. O baseline é o ponto de referência que torna qualquer medição significativa.
Performance sem baseline é opinião. Performance com baseline é engenharia.
O Que É Baseline
Definição
Baseline = Estado conhecido e documentado do sistema
em condições normais de operação
O que NÃO é baseline
❌ "O sistema está rápido"
❌ "Funciona bem no meu computador"
❌ "Nunca tivemos reclamações"
❌ "O último teste deu 200ms"
✅ "Em produção, p95 é 180ms com 500 req/s
entre 10h-12h, medido por 7 dias"
Componentes de um baseline
Métricas:
- Latência (p50, p95, p99)
- Throughput (req/s, tx/s)
- Error rate
- Utilização de recursos
Contexto:
- Período de medição
- Condições de carga
- Versão do sistema
- Configuração de ambiente
Variabilidade:
- Desvio padrão
- Min/max observados
- Padrões temporais
Por Que Baseline É Essencial
1. Medir progresso real
Sem baseline:
"Otimizamos o sistema" → Quanto? Não sabemos.
Com baseline:
Antes: p95 = 450ms @ 1000 req/s
Depois: p95 = 180ms @ 1000 req/s
Melhoria: 60% redução de latência
2. Detectar regressões
Deploy da feature X:
Baseline: p95 = 100ms
Após deploy: p95 = 250ms
Alerta: Regressão de 150% detectada!
3. Validar mudanças
Hipótese: "Adicionar cache vai melhorar performance"
Baseline (sem cache):
p95 = 200ms
DB queries/s = 5000
Após cache:
p95 = 50ms
DB queries/s = 500
Validação: Cache reduziu latência em 75%
e queries em 90%
4. Comunicar com stakeholders
❌ "O sistema está mais rápido"
✅ "Reduzimos tempo de checkout de 3.2s para 0.8s,
impactando 50K transações/dia"
Como Estabelecer um Baseline
Passo 1: Definir métricas relevantes
Para um e-commerce:
Críticas:
- Latência de checkout (p50, p95, p99)
- Taxa de erro em pagamento
- Throughput de pedidos/hora
Secundárias:
- Tempo de busca de produtos
- Latência de login
- Cache hit rate
Recursos:
- CPU do serviço de pedidos
- Conexões de DB
- Memória do Redis
Passo 2: Coletar dados por tempo suficiente
Período mínimo: 1 semana
- Captura variação diária
- Inclui picos e vales
- Representativo de uso real
Período ideal: 1 mês
- Variação semanal
- Eventos especiais
- Maior confiança estatística
Passo 3: Documentar condições
## Baseline - Sistema de Pedidos
**Período:** 2024-01-01 a 2024-01-31
**Versão:** v2.3.4
**Ambiente:** Produção (3x c5.xlarge)
### Métricas
| Métrica | p50 | p95 | p99 |
|---------|-----|-----|-----|
| Checkout | 450ms | 980ms | 2.1s |
| Busca | 80ms | 150ms | 300ms |
| Login | 120ms | 250ms | 500ms |
### Throughput
- Média: 850 req/s
- Pico: 2100 req/s (Black Friday)
- Vale: 150 req/s (madrugada)
### Erros
- Taxa média: 0.3%
- Por tipo: 60% timeout, 30% 5xx, 10% 4xx
### Recursos
- CPU médio: 45%
- Memória: 6.2GB / 8GB
- DB connections: 80 / 100
Passo 4: Identificar padrões
Padrão diário:
┌─────────────────────────────────────┐
│ req/s │
│ 2K ┤ ╭──╮ ╭───╮ │
│ 1.5K┤ ╭╯ ╰╮ ╭╯ ╰╮ │
│ 1K ┤ ╭───╯ ╰───╯ ╰── │
│ 500 ┤──╯ │
│ 0 ├──┬──┬──┬──┬──┬──┬──┬──┬──┬── │
│ 0 3 6 9 12 15 18 21 24 │
└─────────────────────────────────────┘
Picos: 10-12h e 19-22h
Vale: 2-6h
Tipos de Baseline
1. Baseline de produção
Fonte: Métricas reais de produção
Vantagem: Reflete uso real
Desvantagem: Variável, difícil isolar
Quando usar:
- Monitoramento contínuo
- Detecção de regressão
- Planejamento de capacidade
2. Baseline de teste
Fonte: Ambiente controlado com carga simulada
Vantagem: Reproduzível, isolado
Desvantagem: Pode não refletir produção
Quando usar:
- Comparar versões
- Validar otimizações
- Pipeline de CI/CD
3. Baseline teórico
Fonte: SLOs, requisitos, benchmarks de indústria
Vantagem: Meta clara
Desvantagem: Pode ser irrealista
Quando usar:
- Definir objetivos
- Gap analysis
- Negociação com stakeholders
Mantendo o Baseline Atualizado
Quando atualizar
Obrigatório:
- Mudança significativa de arquitetura
- Nova versão major do sistema
- Mudança de infraestrutura
- Crescimento > 50% de usuários
Opcional:
- Trimestralmente
- Após grandes otimizações
- Mudança de padrão de uso
Versionando baselines
## Histórico de Baselines
### v3 - 2024-Q1 (atual)
- Checkout p95: 450ms
- Throughput: 850 req/s
- Contexto: Nova arquitetura de microserviços
### v2 - 2023-Q3
- Checkout p95: 1.2s
- Throughput: 400 req/s
- Contexto: Monolito otimizado
### v1 - 2023-Q1
- Checkout p95: 2.5s
- Throughput: 200 req/s
- Contexto: Monolito original
Erros Comuns
1. Baseline de momento único
❌ "Rodei um teste agora e deu 150ms"
Problema: Não captura variabilidade
2. Ignorar contexto
❌ "p95 é 200ms"
Falta: Com qual carga? Em qual horário?
Qual versão? Qual ambiente?
3. Usar médias em vez de percentis
❌ "Latência média: 100ms"
Problema: Esconde outliers
Realidade: p99 pode ser 5s
4. Nunca atualizar
❌ "Nosso baseline é de 2 anos atrás"
Problema: Sistema mudou completamente
Comparação não faz sentido
Baseline na Prática
Template de documentação
# Baseline de Performance
## Identificação
- **Sistema:** [Nome]
- **Versão:** [x.y.z]
- **Ambiente:** [Produção/Staging]
- **Período:** [Data início] a [Data fim]
- **Responsável:** [Nome]
## Métricas de Latência
| Endpoint | p50 | p95 | p99 | Max |
|----------|-----|-----|-----|-----|
| /api/x | Xms | Xms | Xms | Xms |
## Métricas de Throughput
- Média: X req/s
- Pico: X req/s (quando)
- Vale: X req/s (quando)
## Métricas de Erro
- Taxa geral: X%
- Por tipo: [breakdown]
## Recursos
| Recurso | Média | Pico | Limite |
|---------|-------|------|--------|
| CPU | X% | X% | X% |
| Memória | XGB | XGB | XGB |
## Padrões Observados
[Descrever variações diárias, semanais, etc.]
## Anomalias Conhecidas
[Listar eventos que afetaram métricas]
## Próxima Revisão
[Data prevista]
Automatizando coleta
# Exemplo de job para coletar baseline
baseline_collection:
schedule: "0 0 * * 0" # Semanal
queries:
latency_p95:
promql: histogram_quantile(0.95, rate(http_duration_bucket[7d]))
throughput_avg:
promql: avg_over_time(rate(http_requests_total[5m])[7d:1h])
error_rate:
promql: sum(rate(http_requests_total{status=~"5.."}[7d]))
/ sum(rate(http_requests_total[7d]))
output:
- grafana_annotation
- confluence_page
- slack_notification
Conclusão
O baseline é a fundação de qualquer trabalho sério de performance:
- Sem baseline, não há melhoria mensurável
- Documente o contexto, não só os números
- Use percentis, não médias
- Atualize regularmente conforme o sistema evolui
- Automatize a coleta para consistência
A diferença entre "achamos que melhorou" e "provamos que melhorou" é um baseline bem documentado.
Este artigo faz parte da série sobre a metodologia OCTOPUS de Performance Engineering.