Teste de carga que mente: por que o ensaio passa e a produção cai no mesmo volume

Quase toda ferramenta de teste de carga em uso hoje funciona no mesmo modelo: um número fixo de trabalhadores virtuais, cada um em um laço que envia uma requisição, espera a resposta chegar, opcionalmente pausa por um tempo de reflexão e envia a próxima. Cinquenta trabalhadores com uma resposta de cinquenta milissegundos produzem mil requisições por segundo. É simples de implementar, simples de explicar e é o que a maioria dos relatórios chama de carga.

O problema aparece quando o serviço fica lento. Se a resposta passa de cinquenta para quinhentos milissegundos, cada trabalhador passa a enviar dez vezes menos requisições, e a carga aplicada cai de mil para cem requisições por segundo sozinha, sem que ninguém peça. O gerador reduziu a pressão exatamente no instante em que o serviço estava em dificuldade. O resultado é um ensaio que nunca consegue empurrar um sistema degradado para o colapso, porque ele é, por construção, gentil com sistemas lentos.

Produção não faz isso. O usuário que abre o aplicativo não espera o anterior terminar para clicar, e o parceiro que dispara webhook não reduz a frequência porque a sua resposta demorou. A chegada é independente do serviço, e é esse desacoplamento que produz filas, e são filas que produzem timeouts, esgotamento de pool e a espiral de retry que derruba o serviço. O laço fechado mede capacidade sob autocontrole; produção aplica carga sob indiferença. São duas perguntas diferentes, e o relatório responde à errada.

LACO FECHADO x LACO ABERTO SOB DEGRADACAO

  servico saudavel (50ms)         servico degradado (500ms)

  FECHADO  50 trabalhadores       FECHADO  50 trabalhadores
           1.000 req/s aplicadas           100 req/s aplicadas
           fila = 0                        fila = 0
           "passou"                        "passou, so mais lento"

  ABERTO   1.000 req/s agendadas  ABERTO   1.000 req/s agendadas
           1.000 req/s aplicadas           1.000 req/s aplicadas
           fila = 0                        fila cresce 900/s
                                           timeout, pool cheio, colapso

  O laco fechado converte degradacao em menos carga.
  O laco aberto converte degradacao em fila, que e o que
  produção faz. So o segundo encontra o ponto de ruptura.

Há um caso em que o laço fechado é o modelo correto, e vale reconhecê-lo para não trocar um erro por outro: quando a população de clientes é fechada e cada cliente realmente espera. Um sistema interno com duzentos operadores de call center, cada um trabalhando em uma tela por vez, é um sistema de laço fechado de verdade, e modelá-lo como laço aberto superestima a carga de pico. A regra prática é perguntar se um cliente lento reduz a chegada de novos pedidos. Se reduz, laço fechado. Se não reduz, e quase nunca reduz em serviços expostos a internet, o modelo correto é o aberto.

A consequência estatística do laço fechado tem nome, e o nome é omissão coordenada. Suponha um ensaio de mil requisições por segundo durante cem segundos, com noventa e nove segundos de respostas em um milissegundo e uma pausa de um segundo em que o serviço não respondeu nada. No laço fechado, durante essa pausa os trabalhadores ficaram parados, e portanto quase nenhuma requisição foi registrada nela. O relatório sai com noventa e nove mil medições de um milissegundo e algumas dezenas de um segundo, e o percentil noventa e nove fica em torno de um milissegundo.

A realidade de um sistema de laço aberto é outra. Durante aquela pausa de um segundo, mil requisições deveriam ter sido enviadas e todas elas teriam sofrido espera. A primeira esperaria um segundo inteiro, a segunda novecentos e noventa e nove milissegundos, e assim por diante. Essas mil medições não aparecem no relatório porque o gerador nunca as emitiu: ele coordenou o próprio silêncio com o silêncio do serviço. O percentil noventa e nove verdadeiro é de centenas de milissegundos, e o relatório anuncia um.

A correção não exige trocar de ferramenta, exige mudar o que se mede. Em vez de cronometrar o tempo entre o envio efetivo e a resposta, cronometra-se o tempo entre o instante em que a requisição deveria ter sido enviada, segundo o cronograma definido no início do ensaio, e a resposta. A diferença entre os dois é a espera na fila do próprio gerador, que é exatamente a espera que o usuário real sofre quando o sistema não acompanha.

A segunda linha da tabela merece atenção porque descreve o incidente mais comum de todos. Uma reeleição de líder de quatro segundos é um evento normal e esperado, que acontece em todo failover planejado. No ensaio de laço fechado ela é absorvida silenciosamente e nem entra no relatório. Em produção ela produz quatro segundos de requisições acumuladas que estouram o timeout do cliente, e o cliente reenvia todas elas de uma vez no quinto segundo, dobrando a carga exatamente no instante em que o novo líder está frio. O ensaio aprovou o volume e nunca chegou perto de testar o evento.

Quando o ensaio aprova mil requisições por segundo e produção cai em novecentas, a tentação é concluir que o gerador estava errado sobre o número. Em geral não estava: o número é o mesmo, e o que difere é o que acompanha o número. Seis diferenças respondem pela maior parte dos casos, e todas elas são verificáveis antes do próximo ensaio.

1. Distribuição de chegada. O gerador emite uma requisição a cada milissegundo com régua; produção chega em processo de Poisson, onde intervalos curtos se agrupam. Com a mesma média de mil por segundo, o pico instantâneo de um segundo qualquer em Poisson passa de mil e cem com frequência, e é o pico que satura a fila, não a média.
2. Cardinalidade dos dados. O ensaio repete cem identificadores de cliente e aquece o cache a ponto de a taxa de acerto chegar a noventa e nove por cento. Produção tem duzentos mil clientes distintos e a taxa de acerto real é de sessenta por cento, o que multiplica por quatro as consultas que chegam ao banco com o mesmo número de requisições na borda.
3. Distribuição do trabalho por requisição. O ensaio usa o mesmo corpo de requisição sempre, quase sempre o caso pequeno. Produção tem uma cauda de requisições que custam trinta vezes mais, e é essa cauda que ocupa os trabalhadores e forma a fila para todo o resto.
4. Estado acumulado. O ensaio roda em base recém-restaurada, com índices compactos, estatísticas recentes e nenhuma linha morta. Produção tem seis meses de crescimento, e o mesmo plano de consulta escolhido no ensaio pode nem ser o plano escolhido lá.
5. Concorrência com o resto do mundo. Durante o ensaio o serviço tem o banco só para si. Em produção ele divide com o processo de relatório noturno, com a replicação, com o trabalho em lote das oito da manhã e com o backup, e a capacidade disponível é o que sobra, não o total.
6. Ausência dos vizinhos degradados. O ensaio usa dependências saudáveis e locais. Produção tem um provedor externo que oscila, um serviço interno que reinicia, uma resolução de nome que ocasionalmente demora, e cada um deles transforma capacidade em fila.

Das seis, a primeira é a que se corrige com menos esforço e tem o maior retorno imediato, porque é uma mudança de três linhas no gerador. Emitir com intervalo constante é um erro silencioso: ele reduz a variância da chegada a zero e, com isso, remove o principal mecanismo de formação de fila. Trocar o intervalo constante por um intervalo exponencial, que é o que gera um processo de Poisson, mantém a mesma taxa média e devolve ao ensaio o agrupamento que produção tem.

// Gerador de laco aberto com chegada de Poisson e correcao de
// omissao coordenada. O ponto central e o campo previsto: a medicao
// comeca no instante agendado, nao no instante do envio.

/**
 * @param {object} opcoes
 * @param {string} opcoes.url        endpoint sob teste
 * @param {number} opcoes.taxaPorSeg taxa media de chegada desejada
 * @param {number} opcoes.duracaoSeg duracao total do ensaio
 * @param {number} opcoes.timeoutMs  timeout por requisicao
 */
export async function ensaioLacoAberto({ url, taxaPorSeg, duracaoSeg, timeoutMs = 2000 }) {
  const medicoes = [];
  const emVoo = new Set();
  const inicio = performance.now();
  const fim = inicio + duracaoSeg * 1000;

  // Intervalo exponencial: reproduz chegada de Poisson, onde a media e
  // 1/taxa mas os intervalos se agrupam. Intervalo constante remove a
  // variancia da chegada e, com ela, a formacao de fila que se quer medir.
  const proximoIntervaloMs = () => (-Math.log(1 - Math.random()) / taxaPorSeg) * 1000;

  let previsto = inicio;

  while (previsto < fim) {
    previsto += proximoIntervaloMs();
    const agendadoPara = previsto;

    const esperaMs = agendadoPara - performance.now();
    // Espera apenas quando o gerador esta adiantado. Quando esta atrasado
    // o valor e negativo e a requisicao sai imediatamente, ja devendo
    // tempo: esse debito e a omissao coordenada tornada visivel.
    if (esperaMs > 0) {
      await new Promise((resolve) => setTimeout(resolve, esperaMs));
    }

    const promessa = medirUma({ url, agendadoPara, timeoutMs })
      .then((medicao) => medicoes.push(medicao))
      .finally(() => emVoo.delete(promessa));

    emVoo.add(promessa);
  }

  await Promise.all(emVoo);
  return resumir(medicoes, duracaoSeg);
}

async function medirUma({ url, agendadoPara, timeoutMs }) {
  const enviadoEm = performance.now();
  const controlador = new AbortController();
  const alarme = setTimeout(() => controlador.abort(), timeoutMs);

  try {
    const resposta = await fetch(url, { signal: controlador.signal });
    const concluidoEm = performance.now();
    return {
      // Servico: o que o painel do servidor enxerga.
      servicoMs: concluidoEm - enviadoEm,
      // Resposta: o que o usuario sente, incluindo a espera na fila do
      // proprio gerador. A diferenca entre os dois e a omissao coordenada.
      respostaMs: concluidoEm - agendadoPara,
      status: resposta.status,
      ok: resposta.ok,
    };
  } catch {
    const concluidoEm = performance.now();
    return {
      servicoMs: concluidoEm - enviadoEm,
      respostaMs: concluidoEm - agendadoPara,
      status: 0,
      ok: false,
    };
  } finally {
    clearTimeout(alarme);
  }
}

function percentil(valores, p) {
  if (!valores.length) return 0;
  const ordenado = [...valores].sort((a, b) => a - b);
  const indice = Math.min(ordenado.length - 1, Math.ceil((p / 100) * ordenado.length) - 1);
  return ordenado[indice];
}

function resumir(medicoes, duracaoSeg) {
  const servico = medicoes.map((m) => m.servicoMs);
  const resposta = medicoes.map((m) => m.respostaMs);
  const erros = medicoes.filter((m) => !m.ok).length;

  return {
    amostras: medicoes.length,
    taxaEfetiva: medicoes.length / duracaoSeg,
    taxaErro: erros / Math.max(1, medicoes.length),
    servicoP99: percentil(servico, 99),
    respostaP99: percentil(resposta, 99),
    // A razao abaixo e o indicador mais importante do relatorio inteiro.
    // Perto de 1 o gerador acompanhou o cronograma. Acima de 2 existe
    // fila no gerador, e qualquer numero de latencia do servidor esta
    // subestimando o que o usuario sofre por esse mesmo fator.
    fatorDeOmissao: percentil(resposta, 99) / Math.max(1, percentil(servico, 99)),
  };
}

O campo mais valioso do resumo é o último. A razão entre o percentil noventa e nove da resposta e o percentil noventa e nove do serviço responde, em um único número, se o ensaio pode ser levado a sério. Um valor próximo de um significa que o gerador conseguiu manter o cronograma e que o número de latência do servidor é confiável. Um valor de cinco significa que o gerador acumulou fila, que o servidor já estava saturado durante boa parte do ensaio, e que o percentil bonito do painel do servidor está subestimando a experiência real por um fator de cinco.

Existe uma classe inteira de falhas que é invisível por construção em ensaios curtos, porque o tempo até a manifestação é maior do que a duração do teste. Elas não são exóticas nem raras: são as mais comuns em incidentes de produção, e todas têm em comum o consumo progressivo de um recurso finito que o ensaio curto mal chega a arranhar.

A terceira coluna revela o padrão comum: o ensaio curto não é pequeno demais para a carga, é curto demais para o mecanismo. Um vazamento de dez conexões por minuto precisa de uma hora para consumir um pool de seiscentas, e o ensaio de cinco minutos observa sessenta conexões vazadas, que é indistinguível de operação normal em qualquer painel. Aumentar a carga não ajuda: é preciso aumentar o tempo, ou provocar diretamente o caminho que vaza.

Isso leva a uma divisão de formatos que vale adotar explicitamente, porque cada um encontra uma classe diferente de defeito e nenhum substitui os outros. O ensaio de degrau sobe a carga em patamares até encontrar o ponto de saturação, e responde qual é a capacidade. O ensaio de rajada aplica um salto instantâneo de três a cinco vezes durante trinta segundos, e responde se o sistema absorve pico sem espiral de retry. O ensaio de resistência mantém setenta por cento da capacidade por horas, e responde se existe vazamento. O ensaio de caos aplica carga normal enquanto derruba dependências, e responde se o modo degradado funciona. Aprovar um lançamento com apenas o primeiro é aprovar apenas contra uma das quatro classes de falha.

QUATRO FORMATOS, QUATRO PERGUNTAS DIFERENTES

  DEGRAU        carga
                 |      ___----- ponto de saturacao
                 |  __--
                 |--          pergunta: qual e a capacidade?
                 +---------------- tempo (20 a 40 min)

  RAJADA        carga
                 |    ____
                 |    |  |      pergunta: absorve pico sem
                 |____|  |____  espiral de retry?
                 +---------------- tempo (5 min, salto de 30s)

  RESISTENCIA   carga
                 |________________
                 |                pergunta: vaza algum recurso?
                 +---------------- tempo (2 a 8 horas, 70% da cap.)

  CAOS          carga + falhas injetadas
                 |____X____X______  X = dependencia derrubada
                 |                pergunta: o modo degradado existe?
                 +---------------- tempo (30 a 60 min)

O critério mais usado em teste de carga é também o menos informativo: percentil noventa e cinco abaixo de duzentos milissegundos e taxa de erro abaixo de um por cento na carga alvo. Ele tem dois defeitos estruturais. O primeiro é que ele valida um ponto e não uma curva, então ele não diz absolutamente nada sobre o que acontece com cinco por cento a mais de tráfego, que é a pergunta que interessa na véspera da campanha. O segundo é que ele confunde estar dentro do limite com ter margem, e um sistema que atende ao critério a dois por cento do ponto de ruptura passa exatamente como um que está a cinquenta.

O critério que substitui os dois é o ponto de saturação e a margem até ele. O ponto de saturação é a taxa de chegada acima da qual a vazão útil para de crescer enquanto a latência começa a subir de forma não linear. Ele não é uma escolha, é uma propriedade do sistema, e encontrá-lo é o objetivo do ensaio de degrau. A margem é a razão entre o ponto de saturação e o pico real observado em produção nos últimos noventa dias, e é esse número, e não o percentil, que deve constar do relatório de aprovação.

A terceira linha é a que mais muda a conversa com produto, porque ela mede o que acontece depois do limite e não antes dele. Todo sistema tem um ponto de saturação, e nenhum orçamento evita que ele exista; o que diferencia um serviço resiliente de um frágil é o formato da curva depois dele. Um sistema com controle de admissão recusa o excedente rapidamente e mantém setenta por cento da vazão de pico, o que significa que sete em cada dez clientes continuam sendo atendidos. Um sistema sem controle aceita tudo, forma fila, estoura timeout em todas as requisições e entrega vazão útil próxima de zero, atendendo ninguém enquanto trabalha no limite. Os dois têm a mesma capacidade nominal e resultados opostos no dia do pico.

Vale registrar também o efeito prático dessa mudança de critério no processo. Um relatório que diz percentil noventa e cinco em cento e oitenta milissegundos não permite nenhuma decisão de negócio. Um relatório que diz ponto de saturação em mil e duzentas requisições por segundo, pico de produção em quatrocentas e cinquenta, margem de dois vírgula sete vezes, e vazão útil de setenta e quatro por cento a cento e cinquenta por cento da saturação, permite decidir sobre campanha, sobre capacidade e sobre prioridade de correção sem nenhuma tradução adicional.

Reescrever o ensaio inteiro de uma vez costuma travar antes do primeiro resultado. A sequência abaixo entrega valor em cada passo e pode ser interrompida em qualquer ponto sem perder o que já foi feito, o que importa porque cada passo mostra algo novo e justifica o seguinte.

1. Instrumente a omissão antes de mudar qualquer coisa. Adicione o instante agendado às medições do ensaio atual e publique a razão entre os dois percentis. Se ela passar de dois, você já sabe que todos os relatórios anteriores subestimavam a latência, e isso sozinho costuma ser suficiente para autorizar o restante do trabalho.
2. Troque o intervalo constante pelo exponencial. São três linhas e a taxa média não muda, então a comparação com ensaios anteriores permanece válida. Espere ver o percentil noventa e nove subir sem que nada tenha piorado: o que mudou é que agora ele está sendo medido.
3. Corrija a cardinalidade dos dados antes de qualquer ajuste de infraestrutura. Extraia a distribuição real de identificadores de um dia de log de produção e alimente o gerador com ela. Sem esse passo, toda medição de banco e de cache do ensaio é ficção, e otimizar em cima dela desperdiça semanas.
4. Encontre o ponto de saturação com um ensaio de degrau. Suba em patamares de cinco minutos até a vazão útil parar de crescer, e registre esse número junto com o pico real de produção dos últimos noventa dias. A razão entre os dois é a sua margem, e é o primeiro número do novo relatório.
5. Rode um ensaio de rajada a quatro vezes a média durante trinta segundos. Meça o tempo de recuperação depois do fim da rajada. Esse é o teste que revela retry sem limite e fila sem teto, e ele leva cinco minutos para rodar.
6. Só então rode a resistência de quatro horas a setenta por cento da capacidade, com dois por cento de falha injetada nas dependências. É o ensaio mais caro em tempo de relógio e o único que encontra vazamento, e ele deve rodar de madrugada uma vez por semana, não a cada pedido de mudança.

O terceiro passo é o que mais gera resistência e o que mais muda resultado. Gerar dados sintéticos com cem clientes é rápido e dá um ensaio que roda em qualquer laptop; extrair a distribuição real de um log de produção exige uma conversa sobre acesso a dado e um cuidado de anonimização. A diferença de resultado é grande demais para ignorar: com cem clientes a taxa de acerto do cache fica em noventa e nove por cento e o banco quase não é exercitado, e é justamente o banco que quebra em produção. Uma alternativa aceitável quando o acesso ao log é inviável é reproduzir apenas o formato da distribuição, mantendo a cauda longa de identificadores raros mesmo que os valores sejam gerados.

Sobre a frequência, a divisão que funciona na prática é colocar degrau e rajada no fluxo de entrega, porque juntos levam menos de trinta minutos e pegam regressão de capacidade a cada mudança, e deixar resistência e caos em agenda semanal noturna. Tentar rodar as quatro a cada mudança faz o time desligar o teste inteiro em duas semanas, e um ensaio desligado encontra ainda menos do que um ensaio que mente.