Testes de carga e planejamento de capacidade: quanto seu sistema aguenta
Existe uma pergunta que todo sistema em produção vai enfrentar, cedo ou tarde: quantos usuários simultâneos ele aguenta antes de cair? A pior hora de descobrir a resposta é durante a Black Friday, o lançamento na imprensa ou a campanha que finalmente viralizou. Nesses momentos, o tráfego que a equipe sonhava chega de verdade, e o sistema que "parecia rápido" trava, engasga e derruba a conversão justamente quando ela valia mais. Testes de carga existem para você conhecer o limite do seu sistema antes que o mundo real o encontre por você.
Este guia trata de testar carga e planejar capacidade. Os tipos de teste, como modelar um cenário que se pareça com a realidade, como ler os resultados sem se enganar com médias, e como usar tudo isso para dimensionar o sistema com folga. O foco é o comportamento sob carga, um tema distinto dos testes funcionais que verificam se o software faz a coisa certa.
Testar carga é diferente de testar corretude
Um teste funcional responde "o sistema faz o que deveria?". Um teste de carga responde uma pergunta ortogonal: "o sistema continua fazendo o que deveria sob pressão, e até que ponto?". Um código pode estar perfeitamente correto e ainda assim desabar com mil usuários simultâneos, porque um índice falta, uma conexão de banco esgota ou uma fila entope. Carga revela problemas que nenhum teste de unidade encontra, porque eles só aparecem em escala.
Há vários tipos de teste de carga, cada um respondendo a uma pergunta diferente sobre o comportamento do sistema.
Os tipos de teste
| Tipo | Pergunta que responde | Como funciona |
|---|---|---|
| Load test | Aguenta a carga esperada? | Sobe até o volume normal previsto e sustenta |
| Stress test | Onde é o ponto de ruptura? | Aumenta a carga até o sistema quebrar |
| Soak test | Aguenta carga por muito tempo? | Mantém carga moderada por horas ou dias |
| Spike test | Sobrevive a um pico súbito? | Dispara um salto brusco de tráfego de uma vez |
Load test
O load test verifica se o sistema atende a carga esperada com a performance desejada. Você simula o volume normal de pico (digamos, o tráfego de uma terça-feira movimentada) e confirma que as respostas seguem rápidas e sem erros. É o teste de rotina, o que valida que o dimensionamento atual dá conta do dia a dia.
Stress test
O stress test vai além do esperado, aumentando a carga até o sistema quebrar, para descobrir onde fica o limite e como ele falha. Falhar bem (recusando requisições com elegância, sem corromper dados) é muito diferente de falhar mal (travando, perdendo dados, entrando em colapso). Conhecer o ponto de ruptura e o modo de falha é o que permite planejar margem e defesas.
Soak test
O soak test (ou teste de resistência) mantém uma carga moderada por muito tempo, horas ou dias. Ele caça problemas que só aparecem com o tempo: vazamentos de memória que crescem devagar, conexões que não são liberadas, discos que enchem, filas que acumulam. Um sistema pode passar em um load test de dez minutos e morrer depois de seis horas de tráfego contínuo.
Spike test
O spike test simula um salto súbito de tráfego, aquele momento em que uma menção viral ou uma campanha derruba dez vezes o volume normal de uma vez. Ele verifica se o sistema absorve o choque e se recupera, ou se o autoscaling reage rápido o bastante para acompanhar.
Modelar um cenário realista
O erro mais comum em teste de carga é testar algo que não se parece com a realidade. Disparar um milhão de requisições idênticas ao mesmo endpoint não diz quase nada sobre como o sistema se comporta com usuários de verdade. Um bom teste modela o comportamento real:
- Misture as jornadas. Usuários reais navegam, buscam, adicionam ao carrinho, finalizam, cada ação com peso diferente. O teste deve refletir essa mistura, não um único caminho.
- Inclua tempo de reflexão (think time). Pessoas pausam entre cliques. Um teste sem esses intervalos gera uma pressão irreal e distorce os números.
- Use dados variados. Buscar sempre o mesmo termo esquenta o cache e mascara o custo real. Varie as entradas para exercitar o sistema como o público faz.
- Suba a carga gradualmente. Um aumento em rampa mostra como a performance se degrada ponto a ponto e onde ela começa a virar, em vez de só um sim ou não binário.
Um teste realista custa mais para montar, mas é a diferença entre um número em que você confia e um teatro que dá falsa segurança.
Ler os resultados: percentis, não médias
Aqui está a lição que separa quem entende de performance de quem só olha um número bonito: a média mente. Se 95 requisições respondem em 100ms e 5 respondem em 5 segundos, a média fica em torno de 350ms, um número que parece ótimo e esconde que 5% dos usuários tiveram uma experiência péssima.
O que importa são os percentis. O p95 diz o tempo abaixo do qual ficaram 95% das requisições; o p99, 99 de cada 100. Olhar o p99 é olhar para os piores casos que usuários reais vivem, e são eles que geram reclamação e abandono. Um sistema saudável tem percentis altos controlados, não só uma média boa. Além da latência, acompanhe o throughput (requisições por segundo) e a taxa de erros, que juntos contam a história completa do comportamento sob carga.
Achar e entender os gargalos
Quando a performance degrada, o teste de carga aponta onde está o limite. O gargalo é sempre o recurso que satura primeiro, e costuma ser um destes:
- CPU no teto, sinal de processamento pesado ou código ineficiente.
- Memória esgotada, muitas vezes um vazamento revelado pelo soak test.
- Banco de dados, o gargalo mais comum: conexões esgotadas, queries lentas, falta de índice sob volume.
- Rede ou I/O, quando a saturação está no tráfego ou no disco.
Achar o gargalo é o começo, não o fim. Resolver o primeiro só desloca o limite para o próximo recurso a saturar, e o ciclo de medir, corrigir e medir de novo é o que empurra a capacidade para cima de forma sustentável.
Planejar capacidade com headroom
Testar leva ao objetivo final: planejamento de capacidade, dimensionar o sistema para o tráfego futuro com uma margem de segurança. A palavra-chave é headroom, a folga entre a carga normal e o limite de ruptura. Rodar no talão da capacidade é perigoso: qualquer pico, qualquer degradação, e o sistema tomba. Um bom planejamento mantém uma reserva confortável, para que o inesperado tenha para onde crescer.
O planejamento se apoia em três perguntas: qual é a carga de pico realista, quanta folga o sistema mantém acima dela, e com que rapidez ele escala quando a demanda sobe. Autoscaling ajuda, mas não é mágico: ele leva tempo para reagir, e um spike pode chegar mais rápido do que a capacidade nova sobe. Por isso o headroom não desaparece com o autoscaling; ele continua sendo o colchão que segura o sistema no intervalo entre o pico chegar e a capacidade acompanhar.
Conhecer o limite é dormir tranquilo
Testes de carga transformam a pergunta assustadora "será que aguenta?" em um número conhecido e uma margem planejada. Você descobre o ponto de ruptura em um ambiente controlado, entende como o sistema falha, corrige os gargalos e dimensiona com folga, tudo antes de o tráfego real chegar. A alternativa é descobrir o limite ao vivo, na frente dos clientes, no pior momento possível. Um sistema que conhece a própria capacidade não vive de sustos: ele encara o pico como um evento previsto, não como uma ameaça.
Você sabe exatamente quanto o seu sistema aguenta antes de cair? Na ConstructorTI, fazemos testes de carga realistas e planejamento de capacidade, achando gargalos, lendo percentis e definindo o headroom que mantém o produto de pé no pico. Se um evento de tráfego alto se aproxima ou você teme o próximo viral, fale com a nossa engenharia e receba um diagnóstico da capacidade do seu sistema.