Alice को इंतज़ार पसंद नहीं है

• भले ही सेवा का औसत request time 100ms हो और MTTR 1 मिनट से कम हो, उपयोगकर्ता लंबे requests और लंबे outages में अधिक देर तक फंसे रहते हैं, इसलिए उन्हें औसत प्रतीक्षा समय कहीं अधिक लंबा महसूस होता है
• ऑपरेटर requests और outages को event units में aggregate करते हैं, लेकिन Alice और Alex जैसे उपयोगकर्ता इंतज़ार को सेकंड और मिनट के स्तर पर महसूस होने वाले समय से मापते हैं
• यह अंतर inspection paradox की वजह से होता है, और उपयोगकर्ता जो distribution अनुभव करते हैं वह मूल latency distribution f(t) नहीं बल्कि t से weighted distribution होता है
• जब recovery time का median 30 मिनट और p99 600 मिनट वाले lognormal distribution की बात हो, तब MTTR थोड़ा 1 घंटे से ऊपर होने पर भी ग्राहकों को महसूस होने वाला औसत recovery time लगभग 6 घंटे तक बढ़ सकता है
• tail latency और लंबा recovery time ग्राहक अनुभव पर हावी हो सकते हैं, और trimmed mean दाईं tail की महत्वपूर्ण जानकारी को फेंक देने का जोखिम रखता है

---

request-स्तर के औसत और उपयोगकर्ता-अनुभव वाले औसत के बीच का अंतर

• Alice एक web service का उपयोग करती है और अधिकांश लोगों की तरह समय को सेकंड और मिनट में महसूस करती है
• ऑपरेटर को लग सकता है कि औसत request 100ms में पूरा हो जाता है, लेकिन Alice का औसत wait time 1 सेकंड हो सकता है
• outages में भी यही अंतर पैदा होता है
  • ऑपरेटर कह सकता है कि MTTR 1 मिनट से कम है
  • Alex को महसूस होने वाला औसत outage time 1 घंटा हो सकता है
• दोनों माप एक ही समय में सही हो सकते हैं
  • लंबे requests या लंबे outages ऑपरेटर की गिनती में एक ही event होते हैं
  • लेकिन उपयोगकर्ता के समय में वे अपनी अवधि के अनुपात में अधिक महत्व ले लेते हैं

inspection paradox से बनने वाला t-weighted distribution

• इस phenomenon को inspection paradox के रूप में देखा जा सकता है
• उपयोगकर्ता latency distribution f(t) को सीधे नहीं, बल्कि उसके t-weighted version को अनुभव करता है
• जब MTTR या औसत request time E[X] हो, तो उपयोगकर्ता द्वारा अनुभव किया गया औसत इस प्रकार होता है
  • E_a[X] = E[X²] / E[X]
  • E_a[X] = E[X] + Var(X) / E[X]
• variance जितना बड़ा होगा, उपयोगकर्ता को महसूस होने वाला औसत ऑपरेशनल metrics के औसत से उतना ही अधिक दूर चला जाएगा

30 मिनट median और 600 मिनट p99 का उदाहरण

• median latency या recovery time और 99th percentile value को रखने पर lognormal distribution fit किया जा सकता है, और service metrics की तुलना ग्राहकों के अनुभव किए गए मानों से की जा सकती है
• उदाहरण के मान इस प्रकार हैं
  • median TTR: 30 मिनट
  • p99 TTR: 600 मिनट, यानी 100 events में से 1 को recover होने में 10 घंटे लगते हैं
• इस स्थिति में MTTR थोड़ा 1 घंटे से ऊपर होता है, लेकिन ग्राहकों द्वारा अनुभव किया गया औसत recovery time लगभग 6 घंटे हो जाता है

tail latency और trimmed mean के जाल

• tail latency और लंबे recovery time को समझना कई कारणों से ज़रूरी है, और multiple samples उनमें से एक है
• service time में timeout-and-retry कुछ latency को छिपा सकता है
  • हालांकि, यह तभी संभव है जब चल रहा request lock या किसी अन्य exclusive resource को पकड़े न हो
• recovery time में इस तरह की छिपावट संभव नहीं होती, इसलिए मोटी tail ग्राहक अनुभव में अधिक सीधे दिखाई देती है
• trimmed mean जैसे truncated metrics ग्राहक अनुभव पर हावी दाईं tail के shape को छिपाने की समस्या रखते हैं
• truncated metrics को पसंद न करने का एक और कारण Little’s Law और capacity utilization से जुड़ा है, जिस पर पहले की एक पोस्ट में चर्चा की गई है

lognormal distribution के उपयोग पर सावधानी

• lognormal distribution को संख्यात्मक गणना की सुविधा के लिए चुना गया है
• lognormal(μ, σ²) का lognormal(μ + σ², σ²) बन जाने वाला गुण है, और यह 0 के पास अच्छी तरह काम करता है
• latency या recovery time metrics के लिए lognormal distribution को खास तौर पर एक अच्छा विकल्प मानना ज़रूरी नहीं है
• आम तौर पर ऐसी समस्याओं को non-parametric methods से देखना बेहतर माना जाता है

[GN⁺]

Lobste.rs की राय

• शीर्षक को Latency and the inspection paradox जैसा, थोड़ा ज़्यादा जानकारी देने वाला बनाना बेहतर होगा
  मौजूदा शीर्षक असल में लगभग शून्य जानकारी देता है 😅

  • लेखक के नज़रिए से देखें तो थोड़ा अस्पष्ट शीर्षक काफ़ी उपयोगी होता है
    क्योंकि इससे उन लोगों के जवाब कम हो जाते हैं जो सिर्फ़ शीर्षक पढ़ते हैं, लेख नहीं

• दिलचस्प है, लेकिन लेखक ने यह क्यों सच है, इसे t-weighted शब्द और फ़ॉर्मूले के अलावा ठीक से समझाया नहीं, इसलिए बात पूरी तरह समझ में नहीं आती
  अच्छा होता अगर इसे इतना साफ़ समझाया जाता कि कोई ऐसा व्यक्ति भी समझ सके जिसे कॉलेज की statistics class याद न हो

  • मान लीजिए एक monitoring dashboard है, तो आम तौर पर वह सभी requests को बराबर मानकर average latency निकालता है

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

    यही E[X] है, और हर request का weight 1/N है
    Alice जो latency महसूस करती है, वह समय के आधार पर है, इसलिए शायद यहीं से time-weighted (t-weighted) आता है
    अगर Alice ने M requests भेजीं, जिनकी latency x_1, x_2, ..., x_M है, तो हम यह पूछ सकते हैं: “Alice के कुल इंतज़ार समय में से कोई भी 1 second चुनें, उस क्षण जिस request का इंतज़ार हो रहा है उसकी latency कितनी है?”
    इस स्थिति में request i का योगदान x_i / (Σ_j x_j) होगा, इसलिए लंबी requests ज़्यादा असर डालती हैं
    इसलिए time-weighted average इस तरह होगा

    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]  
    

    एक आसान उदाहरण लें: अगर एक request की latency 1 second है और दूसरी की 10 seconds, तो सामान्य average 5.5 seconds होगा, लेकिन time-weighted average 1 * (1 / 11) + 10 * 10 / 11 = 9.18s होगा

• इससे जुड़ा हुआ The Inspection Paradox is Everywhere भी देखने लायक है

• मैंने भी वास्तव में इसी तरह की बात पहले सोची थी
  मुझे लगता है इस समस्या को समझाने का सबसे आसान उदाहरण यह है कि bus passengers से पूछा जाए कि bus में कितने लोग सवार हैं
  तब “bus भरी हुई है” जैसा जवाब बहुत ज़्यादा मिलेगा, लेकिन जब bus खाली होती है तब आप किसी से पूछ ही नहीं सकते
  हो सकता है सारी buses खाली हों और सिर्फ़ एक ही bus बहुत भीड़भाड़ वाली हो
  अगर मकसद user perspective से स्थिति का विश्लेषण करना है, तो मुझे लगता है यह statistic सही है

  • graph theory में भी ऐसा ही एक नतीजा है: लगभग हर व्यक्ति के दोस्तों के दोस्तों की संख्या नहीं, बल्कि उसके दोस्त आम तौर पर उससे ज़्यादा दोस्त रखते हैं
    क्योंकि ज़्यादा connections वाले nodes, कम connections वाले nodes की तुलना में दूसरे nodes की adjacency list में ज़्यादा बार दिखाई देते हैं

• अगर यह विषय आपको दिलचस्प लग रहा है, तो Gil Tene's "How not to measure latency" ज़ोरदार सिफ़ारिश है