Testes de carga
Como descobrir o limite do sistema antes que os usuários descubram.
O problema: o limite aparece de repente
Um sistema que responde em 5 ms com 100 usuários não responde em 10 ms com 200, e em 15 ms com 300. Até certo ponto, a latência quase não muda; um pouco depois, ela explode, e os erros começam. Descobrir onde fica esse ponto numa campanha de marketing, numa Black Friday ou depois de um post viral sai caro.
O teste de carga gera tráfego simulado contra o sistema, de forma controlada e medida, para responder: quanto ele aguenta, onde está o gargalo e como se comporta perto do limite e depois dele.
O joelho da curva
Medimos com o k6 contra um servidor que gasta 4 ms de CPU por pedido, preso a um núcleo. A capacidade teórica é de 250 pedidos por segundo (1 segundo dividido por 4 ms). O k6 enviou pedidos a uma taxa constante, por 20 segundos em cada degrau:
| Taxa enviada | Respostas por segundo | p50 | p95 | p99 | Erros |
|---|---|---|---|---|---|
| 100/s | 100 | 4,4 ms | 5,0 ms | 5,8 ms | 0 |
| 150/s | 150 | 4,2 ms | 4,4 ms | 4,6 ms | 0 |
| 200/s | 200 | 4,2 ms | 4,3 ms | 4,5 ms | 0 |
| 230/s | 230 | 4,2 ms | 7,0 ms | 26 ms | 0 |
| 260/s | 247 | 297 ms | 407 ms | 4,25 s | 0 |
| 300/s | 246 | 344 ms | 8,8 s | 10 s | 4,2% |
Até 200 por segundo, nada mudou. A 230, o p99 começou a subir. A 260, um pouco acima da capacidade, a mediana saltou de 4 ms para quase 300 ms, e o servidor não passou de 247 respostas por segundo. A 300, ele continuou nas mesmas 246, e o que sobrou virou fila e erro por tempo esgotado.
Esse é o joelho da curva: o ponto em que o sistema para de absorver mais carga e só acumula fila. Acima dele, mais tráfego não gera mais respostas, gera espera. A teoria das filas explica o formato: com a utilização perto de 100%, o tempo na fila cresce sem limite. Na prática, opere bem abaixo do joelho: a 80% da capacidade medida, há folga para picos e para variações.
Percentis, e não médias
A média engana. No teste com o servidor em pausas (descrito abaixo), a média foi de 151 ms, um número que nenhum usuário viveu: a maioria esperou 5 ms, e uma parte esperou quase um segundo. Os percentis mostram a distribuição:
| Percentil | Significado |
|---|---|
| p50 (mediana) | Metade dos pedidos foi mais rápida que isso |
| p95 | 1 em cada 20 pedidos foi mais lento que isso |
| p99 | 1 em cada 100 pedidos foi mais lento que isso |
Uma página que faz 20 chamadas à API tem grande chance de esbarrar no p95 em pelo menos uma delas. Os percentis altos são a experiência real dos usuários frequentes, e é neles que os objetivos de desempenho devem ser definidos, como mostra o tópico de alertas e SLOs.
Omissão coordenada: o gerador que esconde o problema
Há duas formas de gerar carga:
| Modelo | Como funciona | Representa |
|---|---|---|
| Fechado | N usuários fixos; cada um só pede de novo depois de receber a resposta | Um número fixo de clientes, como trabalhadores processando uma fila |
| Aberto | Pedidos chegam numa taxa, independentemente das respostas | Usuários da internet: cada um chega quando quer, sem saber dos outros |
O modelo fechado tem um efeito colateral grave, a omissão coordenada (coordinated omission): quando o servidor trava, os usuários simulados também param, esperando, e os pedidos que chegariam durante a trava nunca são feitos nem medidos. A ferramenta mede menos pedidos lentos do que os usuários reais teriam.
Testamos com um servidor que trava por 1 segundo a cada 5 segundos, como uma pausa longa do coletor de lixo:
| Gerador | Pedidos | Média | p50 | p95 | p99 |
|---|---|---|---|---|---|
| Fechado: 10 usuários, 0,1 s entre pedidos | 1.521 | 31 ms | 4,7 ms | 8 ms | 995 ms |
| Aberto: 90 pedidos por segundo | 1.762 | 151 ms | 4,5 ms | 848 ms | 975 ms |
O mesmo servidor, com as mesmas pausas. O modelo fechado relatou um p95 de 8 ms: durante cada pausa, só os 10 usuários simulados esperavam, um pedido cada. O modelo aberto continuou enviando 90 pedidos por segundo durante as pausas, todos esperaram, e o p95 foi a 848 ms. Um relatório com o primeiro número diria que o sistema está ótimo.
Na Implementação, o mesmo gerador de modelo aberto, escrito nas cinco linguagens, chegou a p95 entre 850 e 900 ms contra esse servidor, confirmando o k6.
Os tipos de teste
| Teste | Pergunta | Como |
|---|---|---|
| Carga | O sistema aguenta o tráfego esperado? | A taxa do pico previsto, por um tempo |
| Estresse | Onde é o limite, e como o sistema falha? | Aumentar a taxa até o joelho e além |
| Pico | O sistema aguenta um salto repentino? | De pouco para muito em segundos |
| Resistência (soak) | Algo se degrada com o tempo? | A carga normal por horas: vazamentos de memória, conexões, disco |
| Capacidade | Quantas instâncias para o tráfego de amanhã? | Medir uma instância e a escala com mais |
Por que isso importa quando a IA escreve o código
Um assistente que escreve um teste de carga costuma produzir números que tranquilizam:
- Usuários fixos com espera entre pedidos, o modelo fechado, sem saber da omissão coordenada.
- Só a média no relatório.
- Um banco quase vazio e dados repetidos, sempre no cache.
- O gerador na mesma máquina do sistema testado.
- Um único degrau de carga, sem procurar o joelho.
- Testes de poucos segundos, que não mostram vazamentos nem o efeito do coletor de lixo.
O próximo nível compara as ferramentas, os modelos de carga e como interpretar os resultados.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Testes de carga em cinco minutos
Explique em no máximo cinco minutos de leitura o que é um teste de carga, para alguém que nunca mediu quanto o próprio sistema aguenta. Cubra só o essencial: o joelho da curva, percentis em vez de média, modelo aberto e fechado, a omissão coordenada e os tipos de teste (carga, estresse, pico, resistência). Use o exemplo de uma loja que se prepara para uma promoção. No final, me faça três perguntas curtas para eu verificar se entendi, e corrija as minhas respostas.
Filas, utilização e o joelho da curva
Quero entender por que a latência explode quando um sistema chega perto do limite. Aja como um mentor e vá por etapas, esperando a minha resposta em cada uma: 1. Capacidade de um servidor a partir do tempo de cada pedido. 2. Utilização e o tempo na fila, de forma intuitiva, com a Lei de Little. 3. Por que a 90% de utilização a fila já é grande. 4. O que acontece com a vazão e os erros acima da capacidade. 5. Quanto de folga manter em produção. Em cada etapa, me dê números e peça que eu calcule o resultado.
Omissão coordenada
Quero entender a omissão coordenada em testes de carga. Explique: 1. A diferença entre o modelo aberto e o fechado. 2. Por que usuários fixos que esperam a resposta deixam de medir os pedidos que chegariam durante uma pausa do servidor. 3. Um exemplo numérico com um servidor que trava por 1 segundo a cada 5. 4. Como as ferramentas evitam o problema (taxa de chegada, medir a partir do instante planejado). 5. Quando o modelo fechado é o certo. Depois me mostre dois relatórios de teste e pergunte qual deles pode estar sofrendo de omissão coordenada.
Ler o resultado de um teste de carga
Quero aprender a interpretar o resultado de um teste de carga. Me mostre, um de cada vez, cinco resultados diferentes (latência, vazão, erros e métricas do servidor) e peça que eu diga o que está acontecendo: passou do joelho, fila no banco, vazamento de memória, gerador como gargalo, pausas do coletor de lixo. Depois de cada resposta, explique a resposta certa e o próximo passo da investigação.