समस्या और दायरा
एकल-अनुरोध लेटेंसी वितरण, मिश्रित अनुरोधों (composed requests), और सेवा उद्देश्यों पर चर्चा करें। 100,000 अनुरोध प्रति मिनट, 80 ms औसत, 180 ms p95, और 2 s p99 मान लें। ये साक्षात्कार के लिए धारणाएं हैं, उद्योग बेंचमार्क नहीं। किसी विशिष्ट विक्रेता उपकरण के बजाय तर्क और सत्यापन पर ध्यान केंद्रित करें।
साक्षात्कारकर्ता क्या मूल्यांकन कर रहा है
साक्षात्कारकर्ता यह देखना चाहता है कि आप समझते हैं कि औसत कुल कार्य का वर्णन करता है, वितरण के आकार का नहीं। टेल अनुरोध टेनेंट, रूट, निर्भरता (dependency), क्षेत्र, अनुरोध आकार, या पुनर्यासों (retries) के पथ के आधार पर क्लस्टर हो सकते हैं। मजबूत उत्तर मापन सीमाओं, एकत्रीकरण आयामों (aggregation dimensions), उपयोगकर्ता प्रभाव, सर्वर कारणों और एक कार्रवाई-योग्य SLO को परिभाषित करते हैं।
स्पष्टीकरण के लिए प्रश्न
- क्या लेटेंसी पहले बाइट (first byte) तक मापी जाती है या पूर्ण प्रतिक्रिया (complete response) तक?
- क्या p99 प्रति इंस्टेंस, रूट, क्षेत्र, या पूरी सेवा के लिए है, और किस समय अवधि (window) में है?
- क्या टाइमआउट, रद्दीकरण (cancellations), पुनः प्रयास (retries), और कैश हिट शामिल हैं?
- क्या टेल में अनुरोध का आकार, टेनेंट, निर्भरता कॉल, या त्रुटियां बदलती हैं?
- क्या लक्ष्य सभी के लिए सुधार करना है या एक महत्वपूर्ण-पथ (critical-path) टेल बजट की रक्षा करना है?
30-सेकंड का उत्तर ढांचा
“80 ms का औसत और 2 s का p99 एक साथ हो सकते हैं; सबसे धीमा 1% अभी भी उपयोगकर्ता और अपस्ट्रीम टाइमआउट को ट्रिगर कर सकता है। मैं सीमा और विंडो तय करूंगा, फिर रूट, क्षेत्र, इंस्टेंस, टेनेंट, अनुरोध आकार, और निर्भरता के आधार पर वितरण को विभाजित करूंगा। मैं कतारों (queues), पूलों, GC, डिस्क, लॉक, डाउनस्ट्रीम कॉल और पुनः प्रयासों का निरीक्षण करूंगा। समाधान बाधा (bottleneck) के अनुसार होना चाहिए: बंधी हुई कतारें (bounded queues), समझदारी भरे टाइमआउट, बैचिंग या कैशिंग, कम क्रमिक निर्भरताएं, शोर करने वाले टेनेंट का अलगाव, और सीमित पुनः प्रयास बजट। p95/p99 SLO और त्रुटि बजट (error budget) के साथ सत्यापित करें।”
चरण-दर-चरण गहन डिज़ाइन
अवलोकन बिंदुओं को परिभाषित करें: क्लाइंट का कुल समय, एज-टू-सर्विस, सेवा प्रसंस्करण, डाउनस्ट्रीम प्रतीक्षा, और प्रतिक्रिया स्थानांतरण। पहले बाइट या पूर्ण प्रतिक्रिया सिमेंटिक्स चुनें, मोनोटोनिक क्लॉक का उपयोग करें, और सैंपलिंग का दस्तावेजीकरण करें। टाइमआउट और रद्दीकरण को अलग से गिनें; पुनः प्रयासों को मूल अनुरोध से लिंक करें ताकि एक उपयोगकर्ता कार्रवाई को कई स्वतंत्र सफलताओं के रूप में न गिना जाए।
पर्सेंटाइल अनुरोध नमूनों से आने चाहिए; इंस्टेंस p99 मानों का औसत निकालना अमान्य है। रूट, स्थिति (status), क्षेत्र, इंस्टेंस, टेनेंट, अनुरोध आकार, और निर्भरता के आधार पर पर्सेंटाइल और नमूना गणनाओं को विभाजित करें। छोटी विंडो रिग्रेशन को उजागर करती हैं लेकिन उनमें जिटर होता है; लंबी विंडो SLO को स्थिर करती हैं लेकिन एक खराब रिलीज़ को छिपा सकती हैं। दोनों को दिखाएं।
मिश्रित अनुरोध टेल को बढ़ाते हैं। क्रमिक (serial) कॉल अपने चरणों को जोड़ते हैं; समानांतर (parallel) कॉल अधिकतम चाइल्ड लेटेंसी के करीब समाप्त होते हैं। प्रत्येक चरण को बजट सौंपें, ट्रेस स्पैन रिकॉर्ड करें, और फैन-आउट का निरीक्षण करें। एक सेवा का औसत एंड-टू-एंड पेज अनुभव की भविष्यवाणी नहीं कर सकता।
अनुमान लगाने से पहले सहसंबंध (correlation) का निदान करें। कतार की बढ़ती आयु क्षमता या प्रवेश दबाव का संकेत देती है; पूल प्रतीक्षा समवर्तीता सीमाओं (concurrency limits) को इंगित करती है; GC, डिस्क और CPU जिटर टेल बनाते हैं; एक धीमी डाउनस्ट्रीम p99 अपस्ट्रीम में फैलती है। अनुरोध विशेषताओं द्वारा सफल और टाइम-आउट नमूनों की तुलना करें और धीमे ट्रेस के लिए नियंत्रित संदर्भ बनाए रखें।
उपाय को कारण के अनुसार लागू करें। कम क्रमिक कॉल, कैशिंग या बैचिंग निश्चित ओवरहेड को कम करते हैं; बंधी हुई समवर्तीता, बैकप्रेशर, और टेनेंट अलगाव भीड़ (congestion) को रोकते हैं; जिटर के साथ सीमित टाइमआउट और पुनः प्रयास रिट्राई स्टॉर्म से बचाते हैं; अतुल्यकालिक (asynchronous) कार्य सिंक्रोनस पथ से अप्रत्याशित कार्यों को हटाता है। केवल अधिक थ्रेड या प्रतिकृतियां (replicas) जोड़ने से टेल और लंबी हो सकती है।
SLO को एक सीमा (threshold) को पूरा करने वाले योग्य अनुरोधों के अंश के रूप में व्यक्त करें, जैसे 300 ms से कम 99.9%। एक त्रुटि बजट रिलीज़ निर्णयों में लेटेंसी उल्लंघनों और त्रुटियों को जोड़ता है। इसके इनग्रेस (ingress), स्थितियों, कैश सिमेंटिक्स और विंडो का उल्लेख करें। केवल औसत वाला लक्ष्य हरा रह सकता है जबकि सबसे धीमे उपयोगकर्ता प्रभावित होते रहते हैं।
रिलीज़ और ड्रिल्स में वितरण परिवर्तनों को सत्यापित करें। पहले और बाद में p50, p95, p99, अधिकतम, टाइमआउट दर और नमूना गणना की तुलना करें। निर्भरता लेटेंसी इंजेक्ट करें, एक बड़ा-टेनेंट अनुरोध बनाएं, और अलगाव और गिरावट को सत्यापित करने के लिए एक पूल को समाप्त करें। रिकवरी के बाद, केवल माध्य (mean) ही नहीं, कतार ड्रेन और पुनः प्रयास प्रवर्धन (retry amplification) का निरीक्षण करें।
उच्च गुणवत्ता वाला नमूना उत्तर
“80 ms औसत और 2 s p99 का अर्थ है एक स्पष्ट लंबी टेल; सबसे धीमा 1% उपयोगकर्ता या अपस्ट्रीम टाइमआउट को ट्रिगर कर सकता है। मैं समय सीमाओं को मानकीकृत करूंगा, पहले बाइट, पूर्ण प्रतिक्रिया, रद्दीकरण और पुनः प्रयासों को अलग करूंगा, फिर रूट, क्षेत्र, इंस्टेंस, टेनेंट, अनुरोध आकार, और निर्भरता के आधार पर विभाजित करूंगा। एक पेज क्रमिक कॉलों को भी जोड़ता है और समानांतर कॉलों का अधिकतम लेता है, इसलिए ट्रेस स्पैन को प्रति-चरण बजट की आवश्यकता होती है।
कतारों, पूलों, GC, डिस्क, या डाउनस्ट्रीम लेटेंसी की पहचान करने के बाद, मैं बंधी हुई समवर्तीता, कैशिंग या बैचिंग, कम क्रमिक निर्भरता, टेनेंट अलगाव और सीमित पुनः प्रयासों का उपयोग करूंगा। मैं 99.9%-अंडर-300-ms SLO, एक त्रुटि बजट, और रिलीज़ के दौरान पर्सेंटाइल तुलनाओं के साथ सत्यापन करूंगा, यह सुनिश्चित करते हुए कि त्रुटियों या शुद्धता की समस्याओं को छिपाए बिना टेल में सुधार हो।”
सामान्य गलतियाँ
- केवल औसत रिपोर्ट करना → टेल उपयोगकर्ता गायब हो जाते हैं → पर्सेंटाइल, नमूने और टाइमआउट की रिपोर्ट करें।
- इंस्टेंस p99 मानों का औसत निकालना → पर्सेंटाइल का रैखिक रूप से औसत नहीं निकाला जाता → नमूनों या हिस्टोग्राम बकेट को सही ढंग से एकत्रित करें।
- पुनः प्रयासों को नए उपयोगकर्ता अनुरोधों के रूप में गिनना → लोड और अनुभव गलत तरीके से प्रस्तुत होते हैं → प्रयासों को मूल से लिंक करें।
- केवल सर्वर समय मापना → नेटवर्क, कतार और स्थानांतरण छूट जाते हैं → एक एंड-टू-एंड सीमा परिभाषित करें।
- बिना सीमा के थ्रेड जोड़ना → विवाद (contention) और कतारबद्धता टेल को लंबा करती है → बंधी हुई समवर्तीता और बैकप्रेशर का उपयोग करें।
- हर टाइमआउट पर आँख बंद करके पुनः प्रयास करना → एक रिट्राई स्टॉर्म निर्भरताओं को ध्वस्त कर देता है → बजट, जिटर और डेडलाइन का उपयोग करें।
- एक वैश्विक SLO सेट करना → एक टेनेंट या क्षेत्र चुपचाप खराब हो सकता है → महत्वपूर्ण आयामों द्वारा विभाजित करें।
- रिलीज़ के बाद केवल माध्य पर नजर रखना → रिग्रेशन छिपे रहते हैं → कई पर्सेंटाइल और विंडो की तुलना करें।
अनुवर्ती प्रश्न और उत्तर
अनुवर्ती 1: p99 सबसे धीमा अनुरोध क्यों नहीं है?
p99 का अर्थ है कि लगभग 99% नमूने उस मान से धीमे नहीं हैं; लगभग 1% धीमे हैं। अधिकतम (maximum) किसी एक विसंगति और नमूना आकार के प्रति संवेदनशील होता है, इसलिए दोनों के अलग-अलग उपयोग हैं।
अनुवर्ती 2: एक पृष्ठ में पाँच समानांतर कॉल हैं। आप अनुभव का अनुमान कैसे लगाते हैं?
समानांतर चरण अधिकतम चाइल्ड लेटेंसी प्लस क्लाइंट शेड्यूलिंग और ट्रांसफर के करीब होता है। पेज के कुल समय को मापें और ट्रेस करें कि कौन सा चाइल्ड अक्सर अधिकतम बन जाता है।
अनुवर्ती 3: उच्च टेल लेटेंसी कब स्वीकार्य है?
ऑफ़लाइन निर्यात या कम-आवृत्ति वाले बैकग्राउंड जॉब थ्रूपुट के लिए लेटेंसी का त्याग कर सकते हैं; इंटरैक्टिव क्रिटिकल पाथ आमतौर पर ऐसा नहीं कर सकते। अनुरोध वर्ग के अनुसार SLO परिभाषित करें।
अनुवर्ती 4: हिस्टोग्राम औसत से बेहतर क्यों हैं?
हिस्टोग्राम बकेट और वितरण आकार को बनाए रखते हैं, जिससे कई पर्सेंटाइल अनुमानों और टेल निरीक्षण की अनुमति मिलती है। एकत्रीकरण के लिए अभी भी बकेट सीमाओं और नमूना गणना पर ध्यान देने की आवश्यकता होती है।
अनुवर्ती 5: आप कतार टेल को डाउनस्ट्रीम टेल से कैसे अलग करते हैं?
प्रतीक्षा, प्रसंस्करण, और डाउनस्ट्रीम स्पैन को अलग से रिकॉर्ड करें। कतार और सेवा समय का एक साथ बढ़ना क्षमता की समस्या का संकेत देता है; केवल डाउनस्ट्रीम में वृद्धि निर्भरता या उसके पुनः प्रयासों की ओर इशारा करती है।
अनुवर्ती 6: एक त्रुटि बजट लेटेंसी कार्य में कैसे मदद करता है?
सीमा उल्लंघनों को बजट खपत के रूप में गिनें। तेजी से बजट की खपत जोखिम भरे रिलीज़ को रोकती है और टेल फिक्स को प्राथमिकता देती है; शेष बजट नियंत्रित प्रयोगों की अनुमति देता है।