Percentis e Latência de Cauda

O painel da BoxOffice diz que o endpoint do mapa de lugares tem latência média de 55 ms. Todos estão contentes — menos os fãs, que reclamam nas redes sociais que o mapa de lugares "demora uma eternidade" durante as aberturas de vendas. Os dois lados têm razão. A média é 55 ms; mas uma requisição em cada cem leva mais de meio segundo, e um fã que abre o mapa de lugares, atualiza, amplia dois setores e tenta três reservas faz requisições suficientes para cair numa dessas lentas quase toda visita. Esta página trata das requisições lentas: como medi-las, por que importam mais do que a média sugere e por que ficam piores à medida que os sistemas ficam mais distribuídos.

Por que médias mentem

Distribuições de latência não são curvas de sino. A maioria das requisições é rápida e parecida; uma minoria — que pega um cache miss, uma pausa de coleta de lixo, um lock, uma nova tentativa, uma conexão fria — é muito mais lenta. O resultado é uma cauda longa à direita. O gráfico mostra uma distribuição sintética, mas realista, para 100.000 requisições: 97% são "normais" (em torno de 40 ms) e 3% pegam um caminho lento (em torno de 400 ms):

A média (cerca de 55 ms) não descreve nenhuma requisição real: ela é puxada para cima pela cauda e, ainda assim, esconde quão ruim a cauda é. A mediana diz o que uma requisição típica experimenta. O p99 e o p99.9 dizem o que as requisições azaradas experimentam — e são cerca de 12× e 28× mais lentas que a mediana (≈ 510 ms e ≈ 1,1 s contra ≈ 40 ms). Um painel que mostra só a média jamais revelaria isso.

Percentis

O p-ésimo percentil (escrito pXX) de um conjunto de latências é o valor abaixo do qual ficam XX% delas¹:

Para calcular um percentil exatamente, ordene os valores e pegue o da posição ⌈p × n⌉ (o método do posto mais próximo): com 1.000 requisições, o p99 é a 990ª mais rápida. Em produção, os sistemas não guardam cada latência; eles registram histogramas — contagens de requisições por faixa de latência (0–5 ms, 5–10 ms, …) — e estimam os percentis a partir das faixas. Histogramas do Prometheus, o HdrHistogram e os histogramas exponenciais do OpenTelemetry funcionam assim (aula 9).

Por que a cauda importa mais do que "1%" sugere

1. Usuários fazem muitas requisições. Uma visita de um fã durante uma abertura de vendas (página do evento, mapa de lugares, atualizações, reservas, pagamento, confirmação) envolve facilmente 50 requisições. A probabilidade de que pelo menos uma seja mais lenta que o p99 é \(1 - 0.99^{50} \approx 39\%\). A "cauda de 1%" é sentida por quatro em cada dez visitas.
2. Os usuários mais lentos costumam ser os melhores clientes. Fãs com muitos pedidos, organizadores com eventos grandes, contas com muitos dados — suas requisições fazem mais trabalho e caem na cauda. A Amazon ficou famosa por definir suas metas internas de latência no p99.9 por esse motivo².
3. A cauda é onde a sobrecarga começa. Como mostram as curvas de filas, o p99 sobe muito antes da média quando um componente se aproxima da saturação. É o aviso mais precoce que você recebe.

Amplificação da cauda sob fan-out

Backends modernos raramente respondem a uma requisição com uma única chamada. A página do mapa de lugares da BoxOffice chama inventory (disponibilidade), catalog (layout do local e preços), order (os ingressos que o fã já tem) e um serviço de recomendações, em paralelo; o serviço de busca consulta 20 shards de índice em paralelo e combina os resultados. Uma requisição que faz fan-out para N backends em paralelo é tão lenta quanto o mais lento deles.

Se cada chamada a um backend é lenta (acima do seu p99) com probabilidade q = 1%, de forma independente, a probabilidade de que a requisição do usuário espere por pelo menos uma chamada lenta é:

Essa é a observação central de The Tail at Scale, de Dean e Barroso³: com fan-out de 100, um backend cujo p99 é 1 segundo faz 63% das requisições dos usuários levarem mais de 1 segundo. Num grande sistema distribuído, a cauda do backend vira a mediana do usuário. Quanto mais você divide um sistema em pedaços paralelos (shards, microsserviços), mais a lentidão rara de cada pedaço passa a dominar.

De onde vem a cauda

A latência de cauda raramente é causada pelo caminho "normal" do código. Causas típicas³:

Domando a cauda

Você não consegue eliminar a variabilidade; consegue projetar para que ela não chegue ao usuário.

• Hedged requests: envie a requisição a uma réplica; se ela não responder dentro de, digamos, a latência p95, envie uma segunda cópia a outra réplica e use a que responder primeiro. Só ~5% das requisições são duplicadas, mas a cauda encolhe drasticamente. Dean e Barroso relatam um caso do Google em que fazer hedging após 10 ms reduziu o p99.9 de uma leitura de 1.000 chaves de 1.800 ms para 74 ms, com apenas 2% mais requisições³. Faça hedging só de leituras idempotentes.
• Tied requests: envie para duas réplicas ao mesmo tempo, cada uma sabendo da outra; a primeira a começar o processamento cancela a outra. Remove a variabilidade de fila ao custo de um pouco de coordenação.
• Reduza o fan-out: menos partições, e maiores, para caminhos críticos em latência; pré-calcule agregados (um resumo materializado do mapa de lugares em vez de chamar cinco serviços).
• Degrade com elegância: dê a cada backend um prazo e devolva uma resposta parcial — o mapa de lugares sem o painel de recomendações ainda é um mapa de lugares.
• Tire trabalho do caminho crítico: o que não precisa terminar antes da resposta (e-mails, analytics, indexação de busca) vai para uma fila.
• Mantenha a utilização baixa nos componentes críticos em latência e isole-os do trabalho em lote.

Orçamentos de latência

Uma meta voltada ao usuário precisa ser dividida entre os componentes do caminho. Para o checkout da BoxOffice (p99 < 1,5 s):

Somar p99s é pessimista (raramente todos acontecem na mesma requisição), e é exatamente o que você quer num orçamento. Quando uma etapa estoura seu orçamento, você sabe de quem é o problema. Cada orçamento também define o timeout daquele componente — um timeout maior que o orçamento inteiro de quem chama não protege nada.

Medindo percentis com honestidade

Duas armadilhas fazem a latência de cauda parecer melhor do que é:

• Omissão coordenada (coordinated omission): um gerador de carga que só envia a próxima requisição depois que a anterior volta para de enviar quando o servidor trava — então ele nunca registra as requisições que teriam chegado durante a trava, e a cauda some dos resultados. Use ferramentas que mantêm uma taxa de chegada constante (modelo aberto: o constant-arrival-rate do k6, wrk2) e compare os horários de envio pretendidos e reais⁴. A aula 15 aprofunda o tema.
• Medir no lugar errado: o próprio cronômetro do servidor não vê o tempo na fila de aceitação, no load balancer e na rede. Meça onde o usuário está (no cliente, ou na borda) e compare com os números do lado do servidor.

export const options = {
  scenarios: {
    open: {
      executor: 'constant-arrival-rate',
      rate: RATE,
      timeUnit: '1s',
      duration: DURATION,
      preAllocatedVUs: Math.max(20, RATE),   // VUs ready to start requests
      maxVUs: Math.max(200, RATE * 10),      // k6 may add more if requests get slow
    },
  },
  summaryTrendStats: ['avg', 'med', 'p(95)', 'p(99)', 'max'],
  thresholds: {
    http_req_failed: ['rate<0.01'],
    'http_req_duration{name:detail}': ['p(99)<500'],
    'http_req_duration{name:list}': ['p(99)<1000'],
  },
};

Experimente: no cenário scale-out, rode o perfil load e anote o p50 e o p99. Depois use chaos em low para deixar uma réplica lenta de vez em quando. Qual percentil se move primeiro? Quanto o p99 se move em comparação com o p50?

Como se conecta

flowchart LR
    DIST["latência de cauda longa"] --> PCT["p50, p99, p99.9<br/>a partir de histogramas"]
    PCT --> SLO["SLOs de latência<br/>→ Confiabilidade"]
    PCT --> OBS["combinar histogramas,<br/>nunca tirar média → Observabilidade"]
    FAN["fan-out N<br/>1 − (1 − q)ᴺ"] --> AMP["a cauda do backend vira<br/>o caso comum (N grande)"]
    DIST --> SRC["fontes: GC, cache misses,<br/>cold starts, dependências lentas"]
    AMP --> TAME["hedging, resultados parciais,<br/>menos fan-out, folga"]
    SRC --> TAME
    TAME --> BUD["orçamentos de latência<br/>e timeouts → Confiabilidade"]
    PCT --> CO["medir no cliente,<br/>omissão coordenada → Performance"]

Componentes da paleta: search (20 shards: a cauda do fan-out) · app (uma página que agrega vários serviços; hedging para outra réplica) · cache (misses são uma fonte de cauda) · serverless (cold starts) · apigw (onde o SLO é medido) · payment (o provedor domina o orçamento do checkout) · metrics (histogramas, nunca média de percentis). Cenários: scale-out (com chaos), search-autocomplete. Continua em: Matemática da Disponibilidade, Observabilidade — SLOs, Confiabilidade — timeouts, Observabilidade — sinais, Performance — testes de carga, Hands-on 2.

Pontos-chave