Latência de cauda: o que é e como medir

Latência de cauda é o tempo de resposta das poucas requisições mais lentas, normalmente informado como percentil 99 ou 99,9. Ela importa porque uma ação do usuário costuma esperar por muitas requisições, então um atraso que atinge 1 requisição em cada 100 pode chegar à maioria dos seus usuários. Um teste de carga que mostra só a média ou a mediana não revela isso.

A tabela supõe que cada chamada é lenta com 1% de chance, de forma independente das outras: a parte é 1 - 0.99^n.

O que conta como cauda?

A cauda é a parte da distribuição de tempos de resposta acima de um percentil alto, quase sempre p99 e p99,9. A mediana descreve uma requisição típica, e a cauda descreve as requisições de que as pessoas reclamam.

Um percentil é um corte: p99 = 800 ms quer dizer que 99% das requisições levaram 800 ms ou menos e 1% levou mais. Num histograma de tempos de resposta, a cauda fica à direita desse corte, muitas vezes como um trecho longo e fino longe do pico principal. Nosso guia de vazão vs latência explica como as ferramentas de teste de carga medem latência e percentis.

Por que a latência de cauda importa tanto?

Porque as requisições se multiplicam. Uma página ou chamada de API que se espalha por muitos serviços só termina quando o mais lento responde, e assim a cauda de cada serviço vira a experiência típica do todo.

A referência é “The Tail at Scale”, de Jeffrey Dean e Luiz André Barroso, publicado na Communications of the ACM em 2013 (PDF do artigo, conferido em 19 de outubro de 2026). O exemplo deles: um servidor que costuma responder em 10 ms mas leva um segundo no percentil 99. Se uma requisição toca um servidor desses, 1 em cada 100 requisições de usuário é lenta. Se ela precisa juntar respostas de 100 deles em paralelo, 63% das requisições de usuário levam mais de um segundo. Mesmo com só 1 chamada lenta em 10.000, um serviço com 2.000 servidores vê quase 1 em cada 5 requisições acima de um segundo.

Eles também relatam medições de um serviço real do Google: o percentil 99 de uma única requisição folha era de 10 ms, mas chegava a 140 ms até todas as requisições folha terminarem, e esperar pelos 5% mais lentos respondia por metade disso.

O que causa a latência de cauda?

Na maior parte, interferência de outro trabalho na máquina ou na rede. A mesma requisição é rápida quase sempre e lenta quando outra coisa está acontecendo.

Dean e Barroso listam os suspeitos de sempre:

• Recursos compartilhados: outro trabalho na mesma máquina disputando núcleos de CPU, caches do processador, banda de memória ou de rede.
• Daemons em segundo plano que acordam e pegam uma fatia da máquina.
• Tarefas de manutenção como compactação de logs ou coleta de lixo em ambientes gerenciados.
• Filas em servidores e switches de rede, que amplificam todas as outras fontes.
• Limites de energia e temperatura que freiam uma CPU depois de um pico de trabalho.

Em testes de carga, a mesma lista aparece como pausas de GC em serviços JVM ou Node.js, pool de conexões esgotado, uma consulta lenta ao banco que só algumas requisições disparam, caches frios depois de um deploy e novas tentativas após um timeout. Uma cauda que cresce com a carga aponta para filas; uma cauda presente mesmo com pouca carga aponta para algo periódico, como GC ou um job agendado.

Como medir a latência de cauda num teste de carga?

Colete amostras suficientes, peça à ferramenta os percentis certos e nunca tire média de percentis entre máquinas ou janelas de tempo.

Amostras suficientes. O p99 é decidido pelo 1% mais lento das requisições, então uma execução com 500 requisições apoia o p99 em 5 delas. Para um p99 estável você precisa de milhares de requisições por transação, e de dezenas de milhares para o p99,9. Testes de fumaça curtos servem para achar erros e pouco para julgar a cauda.

Os percentis certos. Os padrões muitas vezes param antes da cauda. No k6, summaryTrendStats é por padrão avg,min,med,max,p(90),p(95), então o p99 só aparece se você incluir (referência de opções do k6, conferida em 19 de outubro de 2026):

k6 run --summary-trend-stats="med,p(95),p(99),p(99.9),max" \
  script.js

O Aggregate Report do JMeter mostra as linhas de 90%, 95% e 99%, e as propriedades aggregate_rpt_pct1 a aggregate_rpt_pct3 mudam quais percentis aparecem (conferido em 19 de outubro de 2026).

Nada de percentis em média. O p99 de uma execução inteira não é a média dos p99 de cada minuto nem a dos p99 de cada gerador de carga. Junte as amostras brutas ou um histograma e calcule o percentil uma vez só. O artigo sobre coordinated omission trata do HdrHistogram, a ferramenta usual para isso, e de uma segunda armadilha: um gerador de carga que espera as respostas lentas envia menos requisições enquanto o sistema está lento, e esconde justamente a cauda que você procura.

A LoadFocus, que publica este site, mostra em cada execução os blocos P95 e P99, um histograma de tempos de resposta montado a partir das amostras individuais e as requisições mais lentas, então uma cauda longa à direita do pico aparece de relance.

Como definir um limite de aprovação para a cauda?

Coloque um limite no p99 de cada transação importante, ao lado de um limite de p95 e de um limite de taxa de erros. Baseie o limite no que os usuários daquela transação precisam e deixe a execução durar o bastante para o p99 ficar estável.

Um conjunto sensato para uma API de checkout poderia ser: p95 abaixo de 400 ms, p99 abaixo de 1.200 ms e erros abaixo de 0,5%. No k6, são thresholds em http_req_duration como p(99)<1200, e um threshold violado faz o k6 sair com código diferente de zero (thresholds do k6, conferido em 19 de outubro de 2026). A LoadFocus tem um campo Max P99 response time ao lado de Max P95 para testes cloud, JMeter e k6, e cada execução recebe então PASS ou FAIL. Nosso guia de critérios de aprovação de um teste de carga cobre o resto do conjunto.

Se você também reporta uma pontuação Apdex, lembre que ela joga toda requisição acima de quatro vezes T na mesma faixa, então não distingue uma cauda de 2 segundos de uma de 30. O p99 distingue.

Como reduzir a latência de cauda?

Elimine as fontes de variação onde der e desenhe os chamadores para que uma chamada lenta não segure a resposta inteira.

Correções comuns, mais ou menos da mais barata à mais trabalhosa:

• Ajuste o GC e o tamanho dos pools para que pausas e a espera por uma conexão livre continuem curtas sob carga.
• Deixe folga. As filas crescem de repente perto da saturação, então capacidade sobrando encurta a cauda; o guia de vazão vs latência mostra como achar o joelho.
• Defina timeouts e limite as novas tentativas para que uma chamada travada falhe rápido em vez de acumular tudo atrás dela.
• Use requisições de cobertura (hedged requests) em leituras idempotentes: envie uma segunda cópia para outra réplica se a primeira não responder a tempo. Dean e Barroso descrevem enviar a cópia só depois da latência esperada do percentil 95, o que limita a carga extra a cerca de 5%. Num dos testes deles, uma cópia enviada após 10 ms derrubou o percentil 99,9 de 1.800 ms para 74 ms com apenas 2% a mais de requisições.
• Reduza o fan-out. Menos chamadas ao backend por página significa menos chances de cair na cauda, como mostra a tabela do início.

Depois de cada mudança, rode o mesmo teste com o mesmo perfil de carga e compare p99 e p99,9 entre as execuções.

FAQ

Latência de cauda é a mesma coisa que p99? O p99 é a forma mais comum de informá-la, e a cauda é toda a ponta lenta da distribuição. Acompanhe também o p99,9 e o máximo quando a execução tiver requisições suficientes.

Por que meu p99 é tão maior que a minha média? Porque poucas requisições lentas quase não mexem na média e definem o p99 por inteiro. Uma diferença grande é normal; uma diferença que cresce com a carga costuma indicar filas.

Quantas requisições preciso para medir o p99? No mínimo alguns milhares por transação, para que o p99 se apoie em dezenas de requisições lentas. Para o p99,9, planeje dezenas de milhares.

Leituras relacionadas

• Coordinated omission: o que é e como evitar
• Vazão vs latência: como se relacionam sob carga
• Pontuação Apdex: o que é e como calcular
• Critérios de aprovação de um teste de carga: como definir
• Lei de Little em teste de carga: dimensionar e conferir
• YCSB: cargas de trabalho A-F, execução e limites
• SLO vs SLA: a diferença, os SLIs e o orçamento de erros

As afirmações técnicas deste artigo não foram revisadas de forma independente.