Alice odeia esperar

• Mesmo que o tempo médio de requisição do serviço seja de 100ms e o MTTR seja inferior a 1 minuto, os usuários percebem o tempo médio de espera como muito maior, porque ficam presos por mais tempo em requisições longas e falhas longas
• Operadores agregam requisições e falhas por evento, mas usuários como Alice e Alex calculam a espera em tempo percebido em segundos e minutos
• Essa diferença acontece por causa do paradoxo da inspeção (inspection paradox), e a distribuição que o usuário experimenta não é a distribuição original de latência f(t), mas uma distribuição ponderada por t
• Em uma distribuição lognormal com tempo mediano de recuperação de 30 minutos e p99 de 600 minutos, mesmo que o MTTR fique pouco acima de 1 hora, o tempo médio de recuperação percebido pelo cliente pode subir para cerca de 6 horas
• Latência de cauda e tempos longos de recuperação podem dominar a experiência do cliente, e a média aparada (trimmed mean) corre o risco de descartar informações importantes da cauda direita

---

A diferença entre a média por requisição e a média percebida pelo usuário

• Alice usa um serviço web e, como a maioria das pessoas, percebe o tempo em segundos e minutos
• O operador pode ver que a requisição média termina em 100ms, mas o tempo médio de espera de Alice pode ser de 1 segundo
• A mesma diferença aparece em falhas
  • O operador pode dizer que o MTTR é inferior a 1 minuto
  • O tempo médio de falha percebido por Alex pode ser de 1 hora
• As duas medições podem estar corretas ao mesmo tempo
  • Requisições longas ou falhas longas contam como um único evento na agregação do operador
  • No tempo do usuário, elas pesam mais de acordo com sua duração

A distribuição ponderada por t criada pelo paradoxo da inspeção

• Esse fenômeno pode ser visto como o paradoxo da inspeção
• O usuário não experimenta a própria distribuição de latência f(t), mas uma versão ponderada por t
• Quando o MTTR ou o tempo médio de requisição é E[X], a média experimentada pelo usuário é a seguinte
  • E_a[X] = E[X²] / E[X]
  • E_a[X] = E[X] + Var(X) / E[X]
• Quanto maior a variância, maior será a diferença entre a média percebida pelo usuário e a média das métricas operacionais

Exemplo com mediana de 30 minutos e p99 de 600 minutos

• Inserindo o valor mediano de latência ou tempo de recuperação e o valor de percentil 99, é possível ajustar uma distribuição lognormal e comparar as métricas do serviço com os valores percebidos pelo cliente
• Os valores de exemplo são os seguintes
  • TTR mediano: 30 minutos
  • p99 de TTR: 600 minutos, ou seja, 1 em cada 100 eventos leva 10 horas para ser recuperado
• Nesse caso, o MTTR fica pouco acima de 1 hora, mas o tempo médio de recuperação experimentado pelo cliente chega a cerca de 6 horas

Latência de cauda e a armadilha da média aparada

• Há vários motivos para entender a latência de cauda e os tempos longos de recuperação, e multiple samples é um deles
• Em tempos de serviço, timeout-and-retry pode ocultar parte da latência
  • Porém, isso exige que a requisição em execução não esteja segurando locks nem outros recursos exclusivos
• Em tempos de recuperação, esse tipo de ocultação é impossível, então a espessura da cauda aparece de forma mais direta na experiência do cliente
• Medidas truncadas como a trimmed mean têm o problema de esconder a forma da cauda direita, que domina a experiência do cliente
• Outro motivo para não preferir medidas truncadas está relacionado à Lei de Little e ao uso de capacidade, como discutido neste texto anterior

Observações sobre o uso da distribuição lognormal

• A distribuição lognormal foi escolhida por conveniência nos cálculos numéricos
• Ela tem a propriedade de que lognormal(μ, σ²) se torna lognormal(μ + σ², σ²) e funciona bem perto de 0
• Não é necessariamente uma escolha especialmente boa para métricas de latência ou tempo de recuperação
• Em geral, é melhor abordar esse tipo de problema por meio de métodos não paramétricos

[GN⁺]

Opiniões no Lobste.rs

• Talvez fosse melhor mudar o título para algo com mais informação, como Latency and the inspection paradox
  Do jeito que está, o título transmite praticamente zero informação 😅

  • Do ponto de vista do autor, um título um pouco ambíguo é bem útil
    porque reduz as respostas de pessoas que só leram o título e não o texto

• Interessante, mas ficou difícil entender bem porque o autor não explica por que isso é verdadeiro além do termo t-weighted e das fórmulas
  Eu gostaria que tivesse explicado com mais clareza, de um jeito que até quem esqueceu a aula de estatística da faculdade há muito tempo conseguisse entender

  • Se você imaginar que existe um dashboard de monitoramento, normalmente ele trata todas as requisições da mesma forma e calcula a latência média assim

    mean = (sum of all latencies) / (number of requests)  
    

    Isso é E[X], e o peso de cada requisição é 1/N
    A latência que Alice percebe é baseada no tempo, então acho que é daí que vem o peso por tempo (t-weighted)
    Se Alice enviou M requisições com latências x_1, x_2, ..., x_M, podemos perguntar: “Se escolhermos 1 segundo aleatório de todo o tempo de espera da Alice, qual é a latência da requisição que ela está esperando naquele instante?”
    Nesse caso, a requisição i contribui com x_i / (Σ_j x_j), então requisições mais longas entram proporcionalmente mais
    Portanto, a média ponderada pelo tempo fica assim

    E_a[X] = Σ_i x_i (x_i / Σ_j x_j) = Σ_i x_i^2 / Σ_j x_j  
    = (Σ_i x_i^2 / N) / (Σ_j x_j / N)  
    = E[X^2] / E[X]  
    

    Num exemplo simples, se houver uma requisição com latência de 1 segundo e outra de 10 segundos, a média normal é 5,5 segundos, mas a média ponderada pelo tempo vira 1 * (1 / 11) + 10 * 10 / 11 = 9.18s

• Relacionado a isso, também vale a pena ver The Inspection Paradox is Everywhere

• Eu também já pensei em algo parecido na prática
  Acho que o exemplo mais fácil para entender esse problema é uma pesquisa com passageiros de ônibus perguntando quantas pessoas há no ônibus
  Aí você vai receber muito mais respostas do tipo “o ônibus está lotado”, mas quando o ônibus está vazio não há ninguém para perguntar
  Todos os ônibus podem estar vazios, com só um único ônibus cheio
  Se o objetivo é analisar a situação do ponto de vista do usuário, acho que essa estatística faz sentido

  • Existe um resultado parecido em teoria dos grafos: quase todo mundo tem amigos com mais amigos do que si próprio
    porque nós com muitas conexões aparecem com mais frequência na lista de adjacência de outros nós do que nós com poucas conexões

• Se esse tema te interessa, recomendo fortemente Gil Tene's "How not to measure latency"