Um dos erros mais comuns em testes de performance é testar com carga que não representa a realidade. O resultado? Testes que "passam" mas não preveem o comportamento real do sistema.
Workload characterization é o processo de entender, documentar e modelar a carga de trabalho real do seu sistema. É o fundamento de qualquer teste de performance significativo.
Você não pode testar o que não entende. Caracterização vem antes de simulação.
O que é Workload
Workload (carga de trabalho) é a demanda total imposta ao sistema, incluindo:
- Volume: quantidade de requisições, transações, usuários
- Mix: proporção entre diferentes tipos de operações
- Padrão temporal: como a carga varia ao longo do tempo
- Dados: tamanho e distribuição dos dados processados
- Comportamento: sequência de ações dos usuários
Por que Caracterização é Crítica
Testes sem caracterização
"Vamos rodar 10.000 requisições por segundo"
→ Em qual endpoint?
→ Com qual distribuição?
→ Com quais dados?
→ Em qual sequência?
→ Representa produção?
Testes com caracterização
"Vamos simular 5.000 usuários simultâneos com:
- 60% navegação (GET /products)
- 25% busca (GET /search?q=...)
- 10% carrinho (POST /cart)
- 5% checkout (POST /order)
Com padrão de pico às 21h e dados de tamanho médio"
A diferença é entre um número arbitrário e um modelo da realidade.
Dimensões da Caracterização
1. Volume e taxa
- Requisições por segundo (RPS)
- Transações por minuto (TPM)
- Usuários simultâneos
- Sessões ativas
- Dados processados por hora
2. Mix de operações
Raramente um sistema tem apenas um tipo de operação. Caracterize a proporção:
| Operação | Percentual | Custo relativo |
|---|---|---|
| Leitura simples | 70% | 1x |
| Busca | 15% | 5x |
| Escrita | 10% | 10x |
| Relatório | 5% | 50x |
3. Padrão temporal
Como a carga varia:
- Diário: picos em horários específicos
- Semanal: dias mais movimentados
- Mensal: fechamento, início do mês
- Sazonal: Black Friday, férias, eventos
4. Perfil de dados
- Tamanho dos payloads (mínimo, médio, máximo)
- Distribuição de acesso (Pareto: 20% dos dados recebem 80% dos acessos?)
- Dados quentes vs frios
- Taxa de crescimento
5. Comportamento do usuário
- Tempo entre ações (think time)
- Sequência típica de navegação
- Taxa de abandono
- Retry behavior
Métodos de Caracterização
1. Análise de logs
A fonte mais confiável são os logs de produção.
O que extrair:
- Distribuição de endpoints (TOP 20 URLs)
- Distribuição temporal (requests por hora/dia)
- Distribuição de response times
- Distribuição de status codes
- User agents e origens
Ferramentas:
- Scripts personalizados (awk, Python)
- Elasticsearch + Kibana
- Ferramentas de APM
2. Métricas de APM
Ferramentas de Application Performance Monitoring fornecem:
- Throughput por endpoint
- Tempo de resposta por operação
- Traces de transações
- Dependências entre serviços
3. Analytics de produto
Google Analytics, Amplitude, Mixpanel podem revelar:
- Jornadas de usuário
- Funis de conversão
- Tempo em cada página
- Ações mais comuns
4. Entrevistas com stakeholders
Para sistemas novos ou mudanças significativas:
- Qual o crescimento esperado?
- Quais operações são críticas?
- Quais eventos podem causar picos?
Documentando o Workload
Template de caracterização
## Workload: [Nome do Sistema]
### Volume baseline
- RPS médio: 500
- RPS pico (diário): 2.000
- RPS pico (evento): 10.000
### Mix de operações
| Operação | % do tráfego | RPS médio |
|----------|--------------|-----------|
| GET /api/products | 45% | 225 |
| GET /api/search | 20% | 100 |
| POST /api/cart | 15% | 75 |
| GET /api/user | 12% | 60 |
| POST /api/order | 8% | 40 |
### Padrão temporal
- Pico diário: 19h-22h (3x baseline)
- Dia mais movimentado: quinta-feira
- Evento especial: Black Friday (10x baseline)
### Perfil de dados
- Payload médio request: 2KB
- Payload médio response: 15KB
- Catálogo ativo: 50.000 produtos
- 80% dos acessos em 5.000 produtos
### Comportamento
- Think time médio: 30s
- Sessão média: 8 páginas
- Taxa de conversão: 3%
Traduzindo para Testes
Do workload para o script de teste
- Defina cenários baseados no mix de operações
- Configure proporções para refletir distribuição real
- Adicione think time realista entre ações
- Use dados representativos (tamanho, distribuição)
- Simule padrões temporais (ramp-up, steady state, picos)
Exemplo em k6
export const options = {
scenarios: {
browse: {
executor: 'constant-vus',
vus: 450, // 45% de 1000
exec: 'browseProducts',
},
search: {
executor: 'constant-vus',
vus: 200, // 20%
exec: 'searchProducts',
},
cart: {
executor: 'constant-vus',
vus: 150, // 15%
exec: 'addToCart',
},
// ...
},
};
Erros Comuns
1. Usar apenas médias
A média esconde extremos. Um endpoint que representa 5% do tráfego pode consumir 50% dos recursos.
2. Ignorar correlações
Usuários não fazem ações aleatórias. Busca leva a visualização que leva a carrinho. Mantenha a sequência.
3. Dados de teste irreais
Testar com IDs sequenciais quando produção tem distribuição Zipf resulta em cache hits artificiais.
4. Esquecer do crescimento
O workload de hoje não é o de amanhã. Projete cenários futuros.
5. Caracterização única
Workloads mudam. Recaracterize periodicamente, especialmente após mudanças no produto.
Conclusão
Workload characterization é o trabalho invisível que torna testes de performance úteis. Sem ela, você está testando um sistema imaginário.
Invista tempo em:
- Coletar dados reais de produção
- Documentar padrões e distribuições
- Validar com stakeholders
- Atualizar regularmente
O resultado são testes que realmente predizem o comportamento do sistema sob condições reais — e decisões de capacity planning baseadas em dados, não em suposições.
Garbage in, garbage out. A qualidade dos seus testes depende da qualidade da sua caracterização.