Warm-up e Steady State: as fases de um teste de performance

Um erro comum em testes de performance é analisar os dados errados. Os primeiros minutos de um teste raramente representam o comportamento real do sistema — e os últimos minutos podem estar contaminados por efeitos de encerramento.

Entender as fases de warm-up e steady state é essencial para interpretar resultados corretamente e tomar decisões baseadas em dados válidos.

Medir o sistema frio é como avaliar um atleta antes do aquecimento.

As Fases de um Teste

1. Ramp-up

Período de aumento gradual da carga até o nível desejado.

Carga
  │        ╭────────────
  │       ╱
  │      ╱
  │     ╱
  │    ╱
  │───╱
  └────────────────────────
     Ramp    Steady State

Por que fazer ramp-up:

• Evita choque no sistema
• Mais realista (usuários não chegam todos de uma vez)
• Permite identificar em qual ponto o sistema começa a degradar

2. Warm-up

Período inicial onde o sistema ainda está "aquecendo".

O que acontece durante warm-up:

• JIT compilation (Java, .NET, Node.js)
• Preenchimento de caches
• Estabelecimento de pools de conexão
• Alocação inicial de memória
• Carregamento de dados em memória

Resultados durante warm-up:

• Latência mais alta que o normal
• Throughput mais baixo
• Comportamento errático

3. Steady State

Estado estável onde o sistema opera em condições normais.

Características:

• Métricas estabilizam
• Latência consistente
• Throughput previsível
• Uso de recursos estável

É aqui que você mede.

4. Cool-down / Ramp-down

Período de redução gradual da carga.

Por que fazer:

• Evita acúmulo de requisições pendentes
• Permite observar recuperação do sistema
• Mais realista

Por que Warm-up Importa

JIT Compilation

Linguagens como Java, C#, e JavaScript (V8) compilam código em tempo de execução:

Primeira execução: interpretado → lento
Execuções seguintes: compilado → rápido

As primeiras requisições podem ser 10-100x mais lentas que as subsequentes.

Caches frios

Sistemas dependem de múltiplas camadas de cache:

• Cache de aplicação
• Cache de banco de dados
• Cache de sistema operacional
• Cache de CPU

Caches vazios = mais I/O = latência maior.

Conexões não estabelecidas

• Pools de conexão de banco ainda vazios
• Conexões HTTP ainda não estabelecidas
• Handshakes SSL ainda não feitos

Lazy loading

Muitos frameworks carregam recursos sob demanda:

• Classes carregadas na primeira utilização
• Configurações lidas na primeira requisição
• Dependências inicializadas tardiamente

Identificando Steady State

Visualmente

Latência
  │
  │╲
  │ ╲
  │  ╲────────────────────
  │
  └────────────────────────
     Warm-up │ Steady State

A curva se achata quando steady state é atingido.

Estatisticamente

Calcule a variação das métricas em janelas de tempo:

Se desvio padrão(latência) nos últimos 5 min
   < 10% da média
   → provavelmente em steady state

Heurísticas comuns

Sistema	Tempo típico de warm-up
Java (Spring)	2-5 minutos
.NET	1-3 minutos
Node.js	30s-2 minutos
Go	10-30 segundos
Python	30s-1 minuto

Nota: isso varia muito com a aplicação específica.

Configurando Warm-up em Testes

Tempo mínimo recomendado

Duração total do teste = Ramp-up + Warm-up + Steady State + Cool-down

Exemplo:

• Ramp-up: 2 minutos
• Warm-up: 5 minutos (descartado na análise)
• Steady State: 15 minutos (período de medição)
• Cool-down: 2 minutos

Total: 24 minutos

Excluindo warm-up da análise

Opção 1: Configurar no script

// k6 example
export const options = {
  stages: [
    { duration: '2m', target: 100 },   // ramp-up
    { duration: '5m', target: 100 },   // warm-up (tag for exclusion)
    { duration: '15m', target: 100 },  // steady state
    { duration: '2m', target: 0 },     // cool-down
  ],
};

Opção 2: Filtrar na análise Descarte os primeiros N minutos ao calcular métricas.

Opção 3: Pré-aquecer antes do teste Execute uma carga leve antes do teste real para aquecer o sistema.

Warm-up em Produção

O problema do cold start

Novas instâncias em produção também sofrem de warm-up:

• Deploys rolantes
• Autoscaling
• Recuperação de falhas

Estratégias de mitigação

1. Readiness probes inteligentes Não marque a instância como ready até ela estar aquecida.

2. Pre-warming Envie requisições sintéticas para novas instâncias antes de receber tráfego real.

3. Graceful startup Aumente gradualmente o tráfego para novas instâncias.

4. Keep warm pool Mantenha instâncias extras já aquecidas prontas para receber tráfego.

Erros Comuns

1. Testes muito curtos

5 minutos de teste
= 2 min ramp + 3 min steady
= dados insuficientes

Recomendação: mínimo 15-20 minutos de steady state.

2. Incluir warm-up nas métricas

Incluir os primeiros minutos distorce todas as estatísticas:

• Média inflada
• Percentis errados
• Throughput subestimado

3. Não aquecer entre iterações

Ao rodar múltiplos testes, o sistema pode esfriar entre eles. Considere:

• Testes contínuos
• Período de aquecimento entre iterações

4. Esquecer do warm-up de dependências

Seu sistema pode estar quente, mas:

• Banco de dados está frio
• Cache foi limpo
• CDN não tem conteúdo em edge

Conclusão

Warm-up e steady state são conceitos fundamentais para testes de performance confiáveis.

Para testes válidos:

1. Inclua período adequado de ramp-up
2. Espere o sistema atingir steady state
3. Exclua warm-up das métricas finais
4. Mantenha steady state longo o suficiente para dados significativos
5. Considere warm-up de dependências externas

Para produção:

1. Planeje para cold starts em deploys e autoscaling
2. Implemente pre-warming quando possível
3. Use readiness probes que considerem warm-up

O verdadeiro comportamento do sistema só aparece depois que ele aquece. Medir antes disso é medir a exceção, não a regra.