Quando testamos performance, temos duas abordagens fundamentais: criar carga artificial (sintética) ou usar tráfego real. Cada abordagem tem vantagens e limitações. Escolher errado pode dar falsa confiança ou desperdiçar recursos.
Teste sintético mostra o que o sistema pode aguentar. Teste real mostra o que o sistema realmente aguenta.
Testes Sintéticos
O que são
Carga gerada artificialmente por ferramentas como k6, Gatling, JMeter, Locust.
// Exemplo k6
import http from 'k6/http';
export const options = {
vus: 100,
duration: '10m',
};
export default function() {
http.get('https://api.example.com/products');
http.post('https://api.example.com/orders', JSON.stringify({
product_id: 123,
quantity: 1
}));
}
Vantagens
1. Controlável e reproduzível
Teste 1: 1000 VUs, 10 min → Resultado A
Teste 2: 1000 VUs, 10 min → Resultado A (mesmo)
→ Comparações válidas entre versões
2. Escalável
Tráfego real: 5.000 RPS
Teste sintético: 50.000 RPS
→ Pode simular cenários futuros
3. Seguro
- Ambiente isolado
- Dados de teste
- Sem impacto em usuários reais
4. Cenários específicos
- Spike de 10x em 5 segundos
- 100% de um endpoint específico
- Apenas usuários não-autenticados
Limitações
1. Padrões artificiais
Sintético:
- Requests uniformemente distribuídos
- Payloads idênticos
- Timing previsível
Real:
- Rajadas irregulares
- Payloads variados
- Comportamento humano imprevisível
2. Dados de teste vs produção
Sintético com 1.000 produtos:
Query: 5ms
Produção com 10 milhões de produtos:
Query: 500ms
→ Volume de dados muda tudo
3. Dependências mockadas
Mock de pagamento: 10ms fixo
Gateway real: 100-3000ms variável
→ Latência de dependências não é capturada
Testes com Tráfego Real
O que são
Usar tráfego de produção para validar performance.
Técnicas
1. Shadow Traffic (Traffic Mirroring)
Request → App Principal → Response
↓
App Canary (cópia)
↓
Métricas (descarta response)
# Istio mirroring
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
http:
- route:
- destination:
host: app-v1
mirror:
host: app-v2
mirrorPercentage:
value: 100.0
2. Canary Release
100% tráfego → v1
↓
95% → v1, 5% → v2 (observa métricas)
↓
90% → v1, 10% → v2
↓
... gradualmente ...
↓
100% → v2
3. Blue-Green com teste
Blue (produção) ← 100% tráfego
Green (novo) ← Testes sintéticos
Após validação:
Green ← 100% tráfego
Blue ← Standby
Vantagens
1. Padrões reais
- Distribuição real de endpoints
- Mix real de usuários
- Horários de pico reais
2. Dados reais
- Volume de produção
- Queries reais
- Edge cases naturais
3. Dependências reais
- Latência real de APIs
- Comportamento real de cache
- Falhas reais de rede
Limitações
1. Imprevisível
Segunda: 10.000 RPS
Sexta Black Friday: 100.000 RPS
→ Não consegue garantir cenário específico
2. Risco
Bug em produção → Afeta usuários reais
Degradação → Impacto em receita
3. Não reproduzível
Problema às 14:32 → Não consegue recriar exatamente
Comparação
| Aspecto | Sintético | Real |
|---|---|---|
| Controle | Alto | Baixo |
| Reprodutibilidade | Alta | Baixa |
| Risco | Nenhum | Alto |
| Autenticidade | Baixa | Alta |
| Escalabilidade | Ilimitada | Limitada ao tráfego atual |
| Custo | Infra de teste | Minimal |
| Cenários extremos | Fácil | Difícil |
Quando Usar Cada Um
Use sintético quando:
✓ Antes de releases (validação)
✓ Comparando versões (A/B técnico)
✓ Testando limites (stress test)
✓ Cenários específicos (spike, soak)
✓ Ambiente de desenvolvimento
✓ Compliance/auditoria (evidência reproduzível)
Use real quando:
✓ Validação final antes de rollout completo
✓ Monitoramento contínuo de performance
✓ Descoberta de edge cases
✓ Teste de dependências reais
✓ Canary releases
✓ Validação de otimizações em produção
Use ambos quando:
Pipeline completo:
1. Sintético no CI/CD (gate de qualidade)
2. Sintético em staging (validação pré-prod)
3. Canary com real (validação final)
4. Monitoramento em produção (contínuo)
Estratégia Híbrida Recomendada
Fase 1: Desenvolvimento
Sintético local:
- Smoke tests rápidos
- Validação básica de endpoints
- Detecção de regressões óbvias
Fase 2: CI/CD
Sintético automatizado:
- Load test em cada PR
- Baseline comparisons
- Gate de performance
# GitHub Actions exemplo
- name: Performance Test
run: |
k6 run --out json=results.json tests/load.js
- name: Compare with Baseline
run: |
./scripts/compare-perf.sh results.json baseline.json
Fase 3: Staging
Sintético realista:
- Volume próximo de produção
- Dados similares a produção
- Dependências reais ou simuladas com realismo
Fase 4: Canary
Real progressivo:
- 1% tráfego real
- Métricas comparadas com baseline
- Rollback automático se degradação
# Argo Rollouts
spec:
strategy:
canary:
steps:
- setWeight: 1
- pause: {duration: 10m}
- analysis:
templates:
- templateName: success-rate
- setWeight: 5
- pause: {duration: 10m}
...
Fase 5: Produção
Monitoramento contínuo:
- SLOs em tempo real
- Alertas de degradação
- Dashboards de performance
Armadilhas Comuns
1. Só sintético, nunca real
❌ "Passou no load test, está pronto"
→ Produção tem comportamentos não previstos
✅ "Passou no load test, vamos validar com canary"
2. Só real, nunca sintético
❌ "Vamos ver como se comporta em produção"
→ Descobre problema com usuários afetados
✅ "Validamos em staging, agora canary gradual"
3. Sintético com dados irreais
❌ Teste com 100 produtos, produção com 10M
→ Resultados não representativos
✅ Dados de teste proporcionais à produção
4. Ignorar variabilidade do real
❌ Comparar média de sintético com média de real
→ Sintético é estável, real varia muito
✅ Comparar percentis e distribuições
Conclusão
Sintético e real são complementares, não excludentes:
| Sintético | Real |
|---|---|
| Valida capacidade | Valida comportamento |
| Encontra limites | Encontra edge cases |
| Comparável | Autêntico |
| Pré-produção | Produção |
A estratégia ideal:
- Sintético frequente no desenvolvimento e CI/CD
- Sintético intenso em staging antes de releases
- Real gradual via canary para validação final
- Monitoramento real contínuo em produção
O melhor teste é o que você realmente faz. Sintético imperfeito é melhor que nenhum teste.