Load test da coisa certa

Um time me mostra os resultados do load test. Dez mil requisições por segundo, p99 abaixo de cinquenta milissegundos, o gráfico é plano e bonito. Aí eu pergunto qual endpoint foi testado, e a resposta é a home, ou o health check, ou um endpoint de listagem sem filtro que a CDN serviria de qualquer jeito. O teste mediu a velocidade com que o framework devolve uma string. Produção vai falhar no checkout, na busca, no export de relatório, no endpoint que segura uma transação aberta enquanto chama o provedor de pagamento.

Load test é tão útil quanto a escolha do que carregar. Este é o jeito que eu escolho.

Encontre o caminho que falha de verdade

Comece pelo negócio, não pelo servidor. Qual ação do usuário, se falhasse sob carga, custaria mais? Num marketplace é o checkout. Numa clínica é agendar uma consulta. Num produto de analytics é o dashboard com intervalo de datas. Essa ação é o cenário de teste, e o cenário inclui cada passo que um usuário real dá para chegar lá: login, carregar a página, adicionar o item, aplicar o cupom, pagar. Os passos antes do crítico importam porque aquecem caches, seguram sessões e abrem conexões exatamente como produção faz.

Depois olhe o que esse caminho toca. Escritas no banco, não só leituras. Locks em linhas compartilhadas como contagem de estoque ou saldo de conta. Chamadas a serviços externos com a própria latência. Jobs em background que são enfileirados. Um load test que pula qualquer um desses está testando outro sistema.

Modele o tráfego, não o número

'Dez mil requisições por segundo' não é modelo de tráfego. Tráfego real tem forma: um mix de endpoints em proporções conhecidas, uma rampa em vez de um degrau, um conjunto pequeno de registros quentes que a maioria dos usuários toca e uma cauda longa de registros frios. Um teste que bate num endpoint só com ids aleatórios não exercita nenhuma contenção que o tráfego real produz.

Monte o mix a partir dos logs de produção. Pegue uma hora movimentada, conte requisições por rota e replique essas proporções. Pegue a distribuição de ids de registro e preserve, para que os mesmos produtos ou contas populares sejam martelados do jeito que são na realidade. Aumente a carga em rampa ao longo de minutos para enxergar onde a curva dobra, em vez de pular para o alvo e ver só que quebrou.

Teste contra dados com forma de produção

Load test num banco com mil linhas não encontra nada. Os planos de query são outros, os índices cabem na memória, os locks nunca disputam. O banco de teste precisa ter o tamanho de produção, ou ser uma cópia restaurada dela com campos sensíveis limpos. Esse é o motivo mais comum de load test passar e produção falhar.

O mesmo vale para os caches. Cache frio e cache quente são dois sistemas diferentes. Teste os dois: o estado estável com caches quentes, e o momento depois de um deploy ou de um flush em que toda requisição vai para a origem de uma vez.

O que observar enquanto roda

• Percentis de latência por endpoint, não no total, para que um checkout lento não seja escondido por um health check rápido.
• Taxa de erro por endpoint, incluindo os timeouts que o cliente conta como erro e o servidor loga como sucesso.
• Métricas do banco: conexões em uso, esperas de lock, queries mais lentas, lag de replicação.
• Saturação na origem: CPU, memória e principalmente o pool de conexões e o atraso do event loop.
• Profundidade de fila e latência de job para tudo que o caminho testado enfileira.

O resultado que você quer não é um número. É uma frase: 'o checkout segura p99 abaixo de 800 milissegundos até 300 usuários concorrentes, e a partir daí o lock na linha de estoque vira o gargalo'. Essa frase diz o que corrigir, em que tráfego e quanta folga você tem. Um gráfico plano da home não diz absolutamente nada.

Deixe repetível

O primeiro load test é um projeto. O décimo deveria ser um comando. Escreva o cenário em script, versione junto com o código, rode contra um ambiente dedicado com dados em forma de produção e guarde os resultados lado a lado para que uma regressão apareça como mudança na frase acima. Essa é a diferença entre load test como tranquilização única e load test como instrumento.