Alice beklemekten hoşlanmaz

• Hizmetin ortalama istek süresi 100ms ve MTTR 1 dakikanın altında olsa bile, kullanıcılar uzun istekler ve uzun kesintiler içinde daha uzun süre mahsur kaldığı için ortalama bekleme süresini çok daha uzun hisseder
• Operatörler istekleri ve kesintileri olay bazında toplarken, Alice ve Alex gibi kullanıcılar beklemeyi saniye ve dakika cinsinden hissedilen süreyle hesaplar
• Bu farkın nedeni inspection paradox olup, kullanıcının deneyimlediği dağılım asıl gecikme dağılımı f(t) değil, t ile ağırlıklandırılmış dağılımdır
• Ortanca kurtarma süresi 30 dakika, p99 değeri 600 dakika olan log-normal bir dağılımda MTTR 1 saatin biraz üzerinde olsa bile müşterinin hissettiği ortalama kurtarma süresi yaklaşık 6 saate çıkabilir
• Kuyruk gecikmeleri ve uzun kurtarma süreleri müşteri deneyimine hakim olabilir; trimmed mean ise sağ kuyruğa ait önemli bilgileri atma riski taşır

---

İstek bazlı ortalama ile kullanıcının hissettiği ortalama arasındaki fark

• Alice bir web hizmeti kullanır ve çoğu insan gibi zamanı saniye ve dakika olarak hisseder
• Operatörler ortalama bir isteğin 100ms içinde tamamlandığını görse de, Alice'in ortalama bekleme süresi 1 saniye olabilir
• Kesintilerde de aynı fark ortaya çıkar
  • Operatörler MTTR'nin 1 dakikanın altında olduğunu söyleyebilir
  • Alex'in hissettiği ortalama kesinti süresi 1 saat olabilir
• Bu iki ölçüm aynı anda doğru olabilir
  • Uzun istekler veya uzun kesintiler operatör sayımında tek bir olaydır
  • Kullanıcının zamanında ise sürdükleri süre kadar daha büyük ağırlık taşırlar

Inspection paradox'un oluşturduğu t-ağırlıklı dağılım

• Bu olgu inspection paradox ile açıklanabilir
• Kullanıcı, gecikme dağılımı f(t)nın kendisini değil, t ile ağırlıklandırılmış sürümünü deneyimler
• MTTR veya ortalama istek süresi E[X] olduğunda, kullanıcının deneyimlediği ortalama şöyledir
  • E_a[X] = E[X²] / E[X]
  • E_a[X] = E[X] + Var(X) / E[X]
• Varyans büyüdükçe kullanıcının hissettiği ortalama, operasyon metriklerindeki ortalamadan daha fazla uzaklaşır

30 dakikalık ortanca ve 600 dakikalık p99 örneği

• Ortanca gecikme veya kurtarma süresi ile 99. persentil değeri kullanılarak log-normal dağılım uydurulabilir ve hizmet metrikleriyle müşterinin hissettiği değerler karşılaştırılabilir
• Örnek değerler şöyledir
  • Ortanca TTR: 30 dakika
  • p99 TTR: 600 dakika; yani 100 olayın 1'inde kurtarma 10 saat sürer
• Bu durumda MTTR 1 saatin biraz üzerindedir, ancak müşterinin deneyimlediği ortalama kurtarma süresi yaklaşık 6 saat olur

Kuyruk gecikmesi ve trimmed mean tuzağı

• Kuyruk gecikmelerini ve uzun kurtarma sürelerini anlamanın çeşitli nedenleri vardır; multiple samples bunlardan biridir
• Hizmet süresinde timeout-and-retry bazı gecikmeleri gizleyebilir
  • Ancak bunun için çalışmakta olan isteğin lock veya başka münhasır kaynakları tutmuyor olması gerekir
• Kurtarma süresinde böyle bir gizleme mümkün olmadığından kalın kuyruk müşteri deneyimine daha doğrudan yansır
• Trimmed mean gibi budanmış ölçümler, müşteri deneyimine hakim olan sağ kuyruğun biçimini gizleme sorunu taşır
• Budanmış ölçümleri tercih etmemenin bir başka nedeni de Little’s Law ve kapasite kullanımıyla ilgilidir; ilgili yazı daha önce ele alınmıştı

Log-normal dağılım kullanımına dair not

• Log-normal dağılım sayısal hesaplama kolaylığı için seçilmiştir
• lognormal(μ, σ²)nin lognormal(μ + σ², σ²)ye dönüşmesi gibi bir özelliği vardır ve 0 civarında iyi davranır
• Gecikme veya kurtarma süresi metrikleri için log-normal dağılımın özellikle iyi bir seçim olduğunu söylemek zordur
• Bu tür sorunlara genel olarak parametrik olmayan yöntemlerle yaklaşmak daha iyidir

[GN⁺]

Lobste.rs görüşleri

• Başlığı Latency and the inspection paradox gibi daha bilgi veren bir şeyle değiştirmek daha iyi olabilir
  Şu anki başlık neredeyse hiç bilgi vermiyor 😅

  • Yazarın açısından bakınca, biraz muğlak bir başlık oldukça faydalı olabilir
    Çünkü sadece başlığı okuyup metni okumayan insanların verdiği yanıtları azaltır

• İlginç ama yazar bunun neden doğru olduğunu t-weighted terimi ve formül dışında pek açıklamadığı için tam anlayamadım
  Üniversitedeki istatistik derslerini uzun zaman önce unutmuş birinin de anlayabileceği kadar daha açık anlatılsaydı iyi olurdu

  • Bir izleme panosu olduğunu varsayalım; normalde ortalama gecikme süresini hesaplarken tüm istekler eşit kabul edilir

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

    Bu E[X]'tir ve her isteğin ağırlığı 1/N'dir
    Alice'in hissettiği gecikme süresi zamana göre ölçüldüğü için, sanırım burada zaman ağırlıklı (t-weighted) kavramı ortaya çıkıyor
    Alice'in gecikme süreleri x_1, x_2, ..., x_M olan M adet istek gönderdiğini varsayarsak, “Alice'in toplam bekleme süresinden rastgele 1 saniye seçersek, o anda beklemekte olan isteğin gecikme süresi nedir?” diye sorabiliriz
    Bu durumda i numaralı istek x_i / (Σ_j x_j) kadar katkı yapar; yani uzun süren istekler daha fazla yansır
    Dolayısıyla zaman ağırlıklı ortalama şöyle olur

    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]  
    

    Basit bir örnek olarak, biri 1 saniye geciken bir istek ve diğeri 10 saniye geciken bir istek varsa, normal ortalama 5.5 saniyedir ama zaman ağırlıklı ortalama 1 * (1 / 11) + 10 * 10 / 11 = 9.18s olur

• Bununla bağlantılı olarak The Inspection Paradox is Everywhere de okunmaya değer

• Ben de gerçekten buna benzer bir şey düşünmüştüm
  Bence bu problemi anlamanın en kolay örneği, otobüs yolcularına otobüste kaç kişi olduğunu sormaya yönelik bir anket
  Böyle olunca “otobüs tıklım tıklım dolu” yanıtını çok daha sık alırsınız, ama otobüs boşken soracak kimse olmaz
  Tüm otobüsler boş olabilir ve sadece bir tanesi kalabalık olabilir
  Ama amaç durumu kullanıcı açısından analiz etmekse, bunun doğru istatistik olduğunu düşünüyorum

  • Grafik teorisinde de benzer bir sonuç var: neredeyse herkesin arkadaşlarının, kendilerinden daha fazla arkadaşı vardır
    Çünkü çok bağlantılı düğümler, az bağlantılı düğümlere kıyasla diğer düğümlerin komşuluk listelerinde daha sık görünür

• Bu konu size anlamlı geliyorsa Gil Tene's "How not to measure latency" konuşmasını şiddetle tavsiye ederim