औसत का कोई मतलब नहीं

• नई cache layer deploy करने के बाद औसत latency 112ms से बढ़कर 122ms हो गई, लेकिन median 99ms से घटकर 54ms हो गया और p99 309ms से बढ़कर 678ms हो गया, इसलिए सिर्फ एक statistic से सफलता या विफलता तय करना मुश्किल है
• deploy के बाद latency distribution एक peak से टूटकर दो peaks में बंट गया, और cumulative distribution function (CDF) को एक-दूसरे पर रखने से दिखा कि लगभग 140ms की सीमा पर तेज requests बेहतर हुईं जबकि धीमी requests बदतर हुईं
• percentile के हिसाब से बदलाव दिखाने वाला shift function और daily ridgeline graph व heatmap ने सुधार और regression की मात्रा, तथा rollout rate के 0% से 100% तक बढ़ने के दौरान धीमी request समूह के बढ़ने की प्रक्रिया को उजागर किया
• डेटा को cache result और response size के आधार पर बांटने पर छोटे responses के cache hit तेज हुए, जबकि बड़े responses के cache miss अतिरिक्त hop के कारण धीमे हुए, जिससे bimodal distribution का कारण समझ में आया
• अगर केवल औसत या किसी एक percentile को चुना जाए तो एक-दूसरे के उलट निष्कर्ष भी सही ठहराए जा सकते हैं, इसलिए पूरी distribution और subgroups को साथ में देखना चाहिए, तभी cache maximum object size बढ़ाने या बड़े responses को विभाजित करने जैसे कदम निकलते हैं

---

प्रोडक्शन में दिखाई न देने वाला performance improvement

• lld से जुड़ा performance improvement benchmark में दिखा, लेकिन वास्तविक production dashboard में data noise के कारण स्पष्ट बदलाव ढूंढना मुश्किल था
• build speed cold cache, incremental build, local·remote execution, system state, workload जैसे कई variables के अनुसार बहुत बदल सकती है
• cumulative distribution function (CDF) से build performance का मूल्यांकन करने के एक उदाहरण ने यह ज़रूरत पैदा की कि एक image या statistic पर निर्भर रहने के बजाय डेटा को कई तरीकों से देखा जाए
• सभी उदाहरण fixed seed वाले एक synthetic dataset से बनाए गए हैं, और full script में nix-shell shebang शामिल है, जिससे Nix environment में हर figure को उसी तरह दोबारा बनाया जा सकता है
• कहानी के लिए data और charts बनाने में AI का उपयोग किया गया

औसत में असफल दिखा cache rollout

• web service की request latency कम करने के लिए एक हफ्ते तक नई cache layer deploy की गई, लेकिन औसत latency 112ms से 122ms हो गई, यानी 9% बढ़ी
• सिर्फ औसत देखें तो इसे rollback करने और incident response व postmortem शुरू करने लायक regression मानना आसान है

एक ही डेटा से निकले चार निष्कर्ष

• deploy से पहले और बाद के statistics अलग-अलग दिशा दिखाते हैं
  • औसत: 112ms → 122ms, 9% खराबी
  • p50 median: 99ms → 54ms, 46% सुधार
  • p95: 224ms → 454ms, 103% खराबी
  • p99: 309ms → 678ms, 119% खराबी
• औसत हल्का regression दिखाता है, लेकिन median के हिसाब से सामान्य request लगभग दोगुनी तेज हो गई, और p99 के हिसाब से सबसे खराब requests दोगुने से भी ज्यादा धीमी हो गईं
• एक ही डेटा से निकले औसत और median अगर उलटी दिशा दिखाएं, तो अपनी राय के समर्थन में statistic चुन लेना आसान हो जाता है

distribution के आकार ने दो request समूह दिखाए

• density graph में deploy से पहले distribution एक peak था, लेकिन deploy के बाद यह दो peaks में बंट गया
• यह आकार statistics के बीच के विरोधाभास को समझाता है, लेकिन density graph की भी सीमाएं हैं
  • आकार चुने गए smoothing parameter के अनुसार बदलता है
  • अगर दोनों distributions के भरे हुए क्षेत्र overlap करें तो पढ़ना मुश्किल होता है
  • दो समूहों का होना दिखता है, लेकिन median जैसे percentile की स्थिति तुरंत समझना कठिन है

CDF से पूरे percentile range की तुलना

• cumulative distribution function (CDF) हर latency x के लिए x milliseconds या उससे कम समय में पूरी हुई requests का अनुपात दिखाता है
• deploy से पहले और बाद के CDF को एक chart पर रखने से यह देखा जा सकता है कि पूरे request समूह में हर percentile कैसे खिसका
• deploy के बाद curve 140ms से कम वाले हिस्से में बाईं ओर खिसकी, यानी पहले से ज्यादा requests तेज हुईं, लेकिन 140ms के बाद ज्यादा requests धीमी हो गईं
• दोनों curves के कटने वाला लगभग 140ms वह boundary है जहां बदलाव का असर सुधार से खराबी में बदलता है
• जब दो CDF एक-दूसरे को काटते हैं, तो असर की दिशा चुने गए percentile पर निर्भर करती है, इसलिए कोई भी एक percentile पूरे बदलाव का सार नहीं बता सकता

हर percentile पर बदलाव मापना

• CDF दिखाता है कि कौन-सा हिस्सा तेज हुआ या धीमा, लेकिन बदलाव की मात्रा सीधे नहीं बताता
• shift function हर percentile p पर deploy के बाद की latency और deploy से पहले की latency का अंतर निकालता है
  • 0 से नीचे वाला हिस्सा सुधार है
  • 0 से ऊपर वाला हिस्सा slowdown है
• इससे distribution के हर बिंदु पर बदलाव की दिशा ही नहीं बल्कि उसकी मात्रा भी देखी जा सकती है

rollout के दौरान बढ़ता गया regression

• नई cache layer को एक हफ्ते में traffic के 0% से 100% तक धीरे-धीरे बढ़ाया गया, और अगर केवल deploy से पहले और बाद के दो समय बिंदुओं की तुलना की जाए तो बीच के बदलाव छूट जाते हैं
• daily distributions को जमा करके बने ridgeline graph में rollout बढ़ने के साथ तेज requests की मुख्य peak बाईं ओर जाती दिखती है, और धीमी requests की दूसरी peak दाईं ओर उभरती है
• median कम होता जाता है, लेकिन उसी समय धीमी requests की संख्या और latency चुपचाप बढ़ती जाती है
• latency लगभग log-normal distribution का पालन करती है, इसलिए x-axis पर log scale का उपयोग किया गया
  • linear axis पर तेज requests की peak बहुत ऊंची दिखती है और धीमी requests फीली हुई लगती हैं, जिससे दोनों peaks को साथ पढ़ना मुश्किल हो जाता है
• दिनवार columns और latency के हिसाब से traffic volume को रंग से दिखाने वाले heatmap में भी नया request समूह हल्के रूप में दिखाई देता है
• पूरे हफ्ते को एक aggregate value में जोड़ देने पर सात अलग-अलग daily distributions और बदलाव का trend गायब हो जाता है

cache hit और miss में बांटकर समझा bimodal distribution

• वास्तविक lld analysis में binary size, जैसे 50MiB से अधिक या नहीं, के आधार पर डेटा बांटने पर ही latency का bimodal distribution दिखा
• synthetic उदाहरण की नई layer में requests दो हिस्सों में बंटती हैं: cache से serve होने वाले hit और backend तक भेजे जाने वाले miss, जिनमें अतिरिक्त hop लगता है
• deploy के बाद requests के CDF को cache result के आधार पर अलग करने पर हर समूह फिर से single-peak बन जाता है
  • cache hit मौजूदा baseline से बाईं ओर खिसकते हैं, यानी वे तेज हैं
  • cache miss अतिरिक्त hop की लागत के कारण काफी दाईं ओर स्थित हैं

response size में मिला कारण और उपाय

• cache miss केवल एक mechanism है; कौन-सी requests और क्यों miss कर रही हैं, यह समझने के लिए response size को साथ देखना जरूरी है
• cache छोटे और बार-बार उपयोग होने वाले objects को रखता है, लेकिन बड़े objects या तो evict हो जाते हैं या शुरू से ही उसमें नहीं आ पाते
• latency और response size के संबंध को cache hit·miss रंगों से अलग करके, और दोनों axes की density distributions के साथ मिलाकर दिखाने वाले jointplot में दोनों समूह साफ दिखते हैं
  • छोटे response और कम latency वाला समूह cache hit है
  • बड़े response और अधिक latency वाला समूह cache miss है
• latency का bimodal distribution, response size distribution की bimodality से पैदा हुआ था, और इसका समाधान cache maximum object size बढ़ाने या बड़े responses को विभाजित करने से किया जा सकता है

एक graph से आगे, पूरी distribution को देखना

• एक single panel या graph पूरी स्थिति को समेटने के लिए पर्याप्त नहीं होता, और कई बार गलत निष्कर्ष की ओर ले जा सकता है
• एक ही डेटा को कई तरीकों से देखने पर ही distribution का आकार, percentile-वार असर, समय के साथ बदलाव, subgroups और कारणों को साथ में समझा जा सकता है
• खासकर CDF कई request समूहों की तुलना करते हुए पूरी distribution को एक chart में समेटने के लिए उपयोगी है