एपीआई प्रॉक्सी सफलता दर और विलंबता मेट्रिक्स

एपीआई अनुरोधों के लिए प्रॉक्सी सफलता दर और विलंबता कौन-से मेट्रिक्स दिखाते हैं

एपीआई ट्रैफिक तब तक सीधा लगता है, जब तक आपके क्लाइंट और सर्वर के बीच प्रॉक्सी न आ जाए। कोई अनुरोध 200 लौटाकर भी खराब नतीजा दे सकता है, अगर वह 5-सेकंड के टाइमआउट के लिए बहुत देर से पहुँचा हो, या अगर प्रॉक्सी ने पहले बाइट से पहले 900 ms जोड़ दिए हों। सवाल यह नहीं है कि “क्या प्रॉक्सी ने काम किया?” सवाल यह है कि क्या प्रॉक्सी ने उस एपीआई अनुरोध के लिए काम किया जिसे आपने सच में भेजा था।

यह अंतर असली सिस्टमों में मायने रखता है, जहाँ JSON पेलोड, ऑथ हेडर और कड़े रीट्राई नियम होते हैं। एक लॉगिन कॉल और एक बल्क फ़ेच एक जैसे तरीके से फेल नहीं होते। एक ही औसत इस अंतर को जल्दी छिपा देता है, इसलिए कई टीमें पहले यही पूछती हैं कि एपीआई प्रॉक्सी सफलता दर कैसे मापें।

1. पहले यह तय करें कि आप किस एपीआई अनुरोध परिणाम को माप रहे हैं

एक स्पष्ट सीमा से शुरू करें: प्रॉक्सी-हॉप सफलता, HTTP रिस्पॉन्स सफलता, और बिज़नेस सफलता। प्रॉक्सी-हॉप सफलता का मतलब है कि कनेक्शन प्रॉक्सी के जरिए एपीआई तक पहुँच गया। HTTP सफलता का मतलब है कि सर्वर ने वैध रिस्पॉन्स लौटाया, भले ही वह 401 या 429 ही क्यों न हो। बिज़नेस सफलता का मतलब है कि एपीआई कॉल ने आपका ज़रूरी काम पूरा किया, जैसे रिकॉर्ड बनाना, प्रोफ़ाइल पढ़ना, या टोकन रीफ़्रेश करना।

यह विभाजन टीमों को एक भ्रमित करने वाले नंबर पर बहस करने से बचाता है। 201 लौटाने वाला POST एक उपयोगी एपीआई सफलता है। 200 लौटाने वाला GET, लेकिन खाली बॉडी के साथ, आपके वर्कफ़्लो के लिए विफलता हो सकता है। 200 हमेशा जीत नहीं होती।

एपीआई रिपोर्टिंग के लिए, कुछ भी एग्रीगेट करने से पहले हर अनुरोध को एक आउटcome कोड दें। श्रेणियों का एक साधारण सेट काफी है: प्रॉक्सी विफल, HTTP विफल, पेलोड अस्वीकृत, उपयोग योग्य रिस्पॉन्स, और कार्य पूर्ण। श्रेणियाँ स्पष्ट होनी चाहिए, क्योंकि “सफलता दर” का मतलब अलग-अलग लोगों के लिए अलग होता है।

अगर आपकी टीम ब्राउज़र फ़्लो पर भी काम करती है, तो शब्द जल्दी उलझ सकते हैं। वीपीएन और प्रॉक्सी शब्दावली जैसा छोटा संदर्भ नए स्टाफ को ट्रांसपोर्ट शब्दों और एप्लिकेशन शब्दों को मिलाने से बचाता है। फिर भी एपीआई रिपोर्ट अपने आप में स्पष्ट रहनी चाहिए।

2. सफलता दर को अनुरोध वर्ग और मेथड के हिसाब से अलग करें

GET, POST, PUT, और ऑथ कॉल्स को एक ही बकेट में औसत न करें। GET अनुरोध अक्सर साफ़ दिखते हैं क्योंकि वे आइडेम्पोटेंट और छोटे होते हैं। POST और PUT बॉडी-शेप संबंधी कारणों, CSRF चेक, या सर्वर-साइड वैलिडेशन के कारण फेल हो सकते हैं, जो GET को बिल्कुल प्रभावित नहीं करते। एक नंबर यह सब नहीं समझा सकता।

मेथड-स्तर पर विभाजन छोटे एपीआई क्लाइंट में भी उपयोगी है। एक टोकन-रीफ़्रेश एंडपॉइंट 100 में से 99 बार सफल हो सकता है, जबकि एक बल्क-अपडेट POST 12% प्रयासों में फेल हो सकता है क्योंकि प्रॉक्सी देरी जोड़ देता है और सर्वर पुरानी सिग्नेचर को अस्वीकार कर देता है। ये अलग समस्याएँ हैं, और इनके लिए अलग ग्राफ़ होने चाहिए।

ऑथ-संबंधित कॉल्स को भी अलग रखें। लॉगिन पर 401, टोकन एक्सचेंज पर 403, और डेटा फ़ेच पर 200 को एक साथ मिलाना नहीं चाहिए। यह एक आम गलती है जब टीमें केवल होस्ट नाम के आधार पर सफलता दर देखती हैं।

अगर आपका प्रॉक्सी सेटअप क्रेडेंशियल हैंडलिंग पर निर्भर करता है, तो प्रॉक्सी प्रमाणीकरण सर्वोत्तम अभ्यास गाइड को इन मेट्रिक्स के साथ पढ़ना उपयोगी है। प्रमाणीकरण विफलता विलंबता नहीं है, लेकिन अगर आप इसे सावधानी से मार्क नहीं करते, तो वही अनुरोध लॉग बिगाड़ देगी।

3. सिर्फ़ एक औसत नहीं, एंड-टू-एंड विलंबता बैंड इस्तेमाल करें

एक औसत विलंबता आंकड़ा सुविधाजनक भी है और अक्सर बेकार भी। 180 ms के mean वाला प्रॉक्सी पाथ फिर भी 2.4-सेकंड के आउटलायर दे सकता है, जो क्लाइंट टाइमआउट तोड़ देते हैं। p50, p95, और p99 अलग-अलग चीज़ें दिखाते हैं, और एपीआई काम के लिए तीनों चाहिए। यदि आप सोच रहे हैं कि प्रॉक्सी विलंबता p95 p99 क्या है, तो संक्षेप में: p95 वह बिंदु है जहाँ 95% अनुरोध उससे तेज़ होते हैं, और p99 वह टेल है जो सबसे खराब 1% अनुभव दिखाती है।

p50 का उपयोग सामान्य स्थिति समझने के लिए करें। p95 का उपयोग यह देखने के लिए करें कि व्यस्त घंटे में ज़्यादातर उपयोगकर्ता क्या महसूस करते हैं। p99 का उपयोग उस खराब टेल को पकड़ने के लिए करें जो रीट्राई, टाइमआउट, और नाराज़ टिकट पैदा करती है। टेल इसलिए महत्वपूर्ण है क्योंकि एपीआई क्लाइंट आमतौर पर औसत पर नहीं, धीमे किनारे पर फेल होते हैं।

यह व्यावहारिक नियम अपनाएँ: अगर डायरेक्ट ट्रैफ़िक और प्रॉक्सीड ट्रैफ़िक के बीच p95 का अंतर एक सेकंड से ज़्यादा बढ़ जाए, तो प्रॉक्सी पाथ पर नज़र डालनी चाहिए। सही सीमा आपके एपीआई टाइमआउट और बिज़नेस नियम पर निर्भर करती है। पेमेंट एपीआई के पास मेटाडेटा एपीआई से कम धैर्य होता है।

मीडियन विलंबता भी कभी-कभी सच्चाई छिपा सकती है। मिश्रित एग्ज़िट वाले प्रॉक्सी पूल में p50 अच्छा दिख सकता है और फिर भी बर्स्ट लोड पर विफल हो सकता है। इसलिए डैशबोर्ड पर एक लाइन से बेहतर लैटेंसी बैंड होते हैं।

4. क्लाइंट सीमा पर प्रॉक्सी-जोड़ी गई विलंबता मापें

प्रॉक्सी लागत को अलग करने के लिए, क्लाइंट सीमा पर मापें, प्रॉक्सी हॉप से पहले और रिस्पॉन्स लौटने के बाद; क्लाइंट लेवल पर प्रॉक्सी देरी कैसे मापें, इसका सबसे भरोसेमंद तरीका यही है। अगर आपका HTTP लाइब्रेरी टाइमिंग हुक देता है, तो DNS, कनेक्ट, TLS, पहला बाइट, और कुल समय अलग-अलग कैप्चर करें। इससे आपको अनुमान के बजाय जोड़ी गई प्रॉक्सी विलंबता का साफ़ आंकड़ा मिलेगा।

उपयोगी तुलना प्रॉक्सीड बनाम डायरेक्ट की है, उसी एंडपॉइंट, मेथड, पेलोड, और टाइमआउट के साथ। अगर direct GET /v1/profile में 240 ms लगते हैं और प्रॉक्सीड संस्करण में 510 ms, तो प्रॉक्सी ने उस पाथ पर लगभग 270 ms जोड़े। यह ठोस अंतर है, सिद्धांत नहीं।

जब तक कोई और विकल्प न हो, सर्वर प्रोसेसिंग समय को इस नंबर में न मिलाएँ। अगर एपीआई खुद परिवर्तनशील है, तो आपको डायरेक्ट क्लाइंट या स्थिर संदर्भ रूट से कंट्रोल रन चाहिए। वरना प्रॉक्सी पर एपीआई के अपने धीमे काम का दोष आ जाएगा।

कुछ टीमें कोड रिव्यू या रनबुक में छोटा-सा टाइमिंग नोट रखती हैं: अनुरोध भेजने से पहले टाइमर शुरू करें, पूरी बॉडी पढ़ने के बाद रोकें, प्रॉक्सी रूट रिकॉर्ड करें। यह तीन-चरणीय आदत ज़्यादातर एपीआई क्लाइंट्स के लिए पर्याप्त है। इससे बहस भी छोटी रहती है।

5. पहले अनुरोध की लागत और पुन: उपयोग किए गए कनेक्शन के प्रदर्शन को अलग करें

कनेक्शन रीउज़ प्रॉक्सी विलंबता की आकृति बदल देता है। पहला अनुरोध अक्सर TCP सेटअप, TLS, प्रॉक्सी ऑथ, और कभी-कभी DNS की लागत चुकाता है। उसी कनेक्शन पर अगले अनुरोध बहुत तेज़ हो सकते हैं। अगर आप इन्हें एक साथ औसत करते हैं, तो पहला अनुरोध बाकी सब पर भारी पड़ जाता है।

एपीआई क्लाइंट्स के लिए जो कनेक्शन खुले रखते हैं, “कोल्ड” और “वॉर्म” अनुरोध अलग करें। कोल्ड का मतलब नया कनेक्शन या नया सत्र है। वॉर्म का मतलब कनेक्शन पहले से मौजूद है और प्रॉक्सी हैंडशेक पूरा हो चुका है। यह विभाजन तब सबसे ज़्यादा मायने रखता है जब क्लाइंट एक रन में 20 या उससे अधिक कॉल करते हैं।

प्रॉक्सी पहला अनुरोध धीमा और दूसरा ठीक दिखा सकता है। इसका मतलब यह नहीं कि प्रॉक्सी खराब है। इसका मतलब हो सकता है कि हैंडशेक लागत अधिक है, लेकिन स्थिर-स्थिति ट्रैफ़िक स्वीकार्य है। आपके लिए कौन-सा नंबर मायने रखता है, यह इस पर निर्भर करता है कि आपका काम एक कॉल करता है या 1,000।

यह वह जगह है जहाँ प्रॉक्सी टाइप पर एक नोट मदद कर सकता है। अगर आपका स्टैक कुछ रूट्स के लिए SOCKS5 और कुछ के लिए HTTP इस्तेमाल करता है, तो कनेक्शन व्यवहार इतना अलग हो सकता है कि आपको सीधे तुलना करनी चाहिए। SOCKS5 proxy vs HTTP proxy जैसी साधारण तुलना सिर्फ़ स्क्रैपिंग के बारे में नहीं है; एपीआई सत्रों के लिए ट्रांसपोर्ट चुनते समय भी मदद करती है।

6. एंडपॉइंट संवेदनशीलता और पेलोड आकार के आधार पर मेट्रिक्स विभाजित करें

हर एपीआई एंडपॉइंट प्रॉक्सी पर एक जैसा प्रतिक्रिया नहीं देता। छोटे GET अनुरोध अक्सर आसानी से निकल जाते हैं। बड़े POST बॉडी, हस्ताक्षरित अनुरोध, या कड़े समय-संवेदनशील एंडपॉइंट अधिक बार फेल हो सकते हैं। सिर्फ़ होस्ट नहीं, एंडपॉइंट परिवार के हिसाब से नंबर अलग करें।

पेलोड आकार ट्रैक करने योग्य है क्योंकि यह विलंबता और विफलता दर दोनों बदलता है। 2 KB का JSON ऑब्जेक्ट पहली कोशिश में सफल हो सकता है, जबकि 2 MB का अपलोड टाइमआउट या प्रॉक्सी बफ़र सीमा से टकरा सकता है। बड़े पेलोड रीट्राई लागत भी बढ़ा देते हैं। बड़े अनुरोध पर एक अतिरिक्त रीट्राई महँगा पड़ता है।

हेडर भी मायने रखते हैं। कुछ एपीआई हेडर की संख्या, हेडर क्रम, या लंबे ऑथ टोकन के प्रति संवेदनशील होते हैं। अगर प्रॉक्सी हेडर फिर से लिखता है या कोई फ़ील्ड छोड़ देता है, तो विफलता केवल एक ही रूट पर दिखाई दे सकती है। इसलिए आप साइट-व्यापी औसत के बजाय एंडपॉइंट-स्तर के नंबर चाहते हैं।

जब आपको यह समझाना हो कि कोई एक रूट धीमा क्यों है, तो रूट का विवरण मदद करता है। रूट नाम, पेलोड वर्ग, और रिस्पॉन्स कोड एक साथ ट्रैक करें। इन तीन लेबल के बिना मेट्रिक पर भरोसा करना कठिन है।

7. रीट्राई और दर-सीमिती के दौरान विफलता-और-विलंबता की जोड़ियों को ट्रैक करें

रीट्राई एक खराब प्रॉक्सी को उससे बेहतर दिखा सकते हैं जितना वह वास्तव में है। अगर पहली कॉल 429 देती है, दूसरी सफल हो जाती है, और तीसरी कॉल की ज़रूरत ही नहीं पड़ती, तो आपकी कच्ची सफलता दर अच्छी दिख सकती है। असली कहानी जोड़ी में है: पहले विफलता, बाद में सफलता, और उनके बीच इंतज़ार में लगा समय।

हर अनुरोध वर्ग के लिए रीट्राई गिनती, बैकऑफ़ देरी, और अंतिम परिणाम रिकॉर्ड करें। इससे “आखिरकार सफल” और “साफ़-सुथरे ढंग से सफल” के बीच का अंतर दिखता है। दर-सीमिती के तहत एपीआई काम में, दूसरा नंबर ही सिस्टम को अनुमान योग्य बनाता है।

429 और 5xx पैटर्न को साथ-साथ देखें। 429 का मतलब हो सकता है कि प्रॉक्सी रूट साझा सीमा से टकरा रहा है। 502 या 504 का मतलब हो सकता है कि पाथ अस्थिर है। अगर रीट्राई दर p95 विलंबता के साथ-साथ बढ़ती है, तो प्रॉक्सी और एपीआई एक-दूसरे को और खराब कर रहे हो सकते हैं।

यही वह जगह है जहाँ शीर्षक का सटीक वाक्य व्यावहारिक रूप से उपयोगी बनता है: एपीआई अनुरोधों के लिए प्रॉक्सी सफलता दर और विलंबता कौन-से मेट्रिक्स दिखाते हैं, इसका जवाब एक डैशबोर्ड टाइल से नहीं मिलता। आपको एक ही पंक्ति में रीट्राई लॉग, लैटेंसी बैंड, और विफलता कोड चाहिए। एक चार्ट से तीन कॉलम बेहतर हैं।

जो टीमें कई एग्ज़िट मैनेज करती हैं, उनके लिए वेब स्क्रैपिंग के लिए प्रॉक्सी रोटेशन गाइड अब भी प्रासंगिक हो सकती है, क्योंकि रोटेशन नीतियाँ स्क्रैपिंग के बाहर भी रीट्राई व्यवहार को प्रभावित करती हैं। वही बात रूट चर्न पर लागू होती है: अगर आप बहुत आक्रामक तरीके से रोटेट करते हैं, तो आप खराब पाथ को मापने के बजाय छिपा सकते हैं।

8. एपीआई वर्कफ़्लो के लिए हल्का-फुल्का प्रॉक्सी-चयन स्कोरकार्ड बनाएं

स्कोरकार्ड में 20 फ़ील्ड की ज़रूरत नहीं है। पाँच या छह मेट्रिक्स पर्याप्त हैं, अगर वे सही हों: प्रॉक्सी-हॉप सफलता दर, HTTP सफलता दर, p95 विलंबता, p99 विलंबता, पहले अनुरोध की लागत, और रीट्राई-समायोजित पूर्णता दर। यह सूची एक स्क्रीन पर पढ़ने के लिए पर्याप्त छोटी है।

हर प्रॉक्सी पूल को एक ही एपीआई वर्कफ़्लो के खिलाफ स्कोर करें। अगर वर्कफ़्लो टोकन रीफ़्रेश है, तो टोकन रीफ़्रेश को मापें। अगर वर्कफ़्लो बल्क प्रोफ़ाइल लुकअप है, तो बल्क प्रोफ़ाइल लुकअप को मापें। छोटे GETs पर जीतने वाला प्रदाता signed POSTs पर बुरी तरह हार सकता है।

हर पूल के लिए सरल पास/फेल नोट इस्तेमाल करें: टाइमआउट के भीतर, टाइमआउट से ऊपर, वॉर्म कनेक्शन पर स्थिर, या रीट्राई पर अस्थिर। ये लेबल सीधे हैं, और यही वजह है कि वे काम करते हैं। दिखावटी नाम अक्सर विवरण छिपा देते हैं।

अगर आपकी टीम अभी भी प्रदाताओं के बीच चुनाव कर रही है, तो मेट्रिक्स के साथ लागत नोट रखा जा सकता है। लेख प्रॉक्सी की लागत क्या है आपको पैसे और विलंबता की तुलना करने में मदद कर सकता है, क्योंकि 800 ms जोड़ने वाला सस्ता प्रॉक्सी व्यवहार में महँगा विकल्प हो सकता है। कीमत को अनुरोध सफलता से ऊपर नहीं रखना चाहिए।

एपीआई प्रॉक्सी परीक्षणों के लिए एक सरल रिपोर्टिंग तालिका

मेट्रिक्स के साथ उसी पेज पर क्या रखना चाहिए

अनुरोध मेथड, एंडपॉइंट, पेलोड आकार, प्रॉक्सी रूट, और टाइमआउट को नंबरों के साथ रखें। इन पाँच फ़ील्ड के बिना, सफलता-दर चार्ट अंदाज़े का खेल बन जाता है। इनके साथ, आप समझा सकते हैं कि एक रूट धीमा क्यों है और दूसरा क्यों नहीं।

एपीआई ट्रैफ़िक नीरस अनुशासन को पुरस्कृत करता है। पहला अनुरोध अलग मापें। GET और POST अलग-अलग तुलना करें। केवल औसत नहीं, p95 पर नज़र रखें। ज़्यादातर टीमों के लिए इतना पर्याप्त है ताकि वे साफ़ प्रॉक्सी चुनाव कर सकें।

एक आख़िरी व्यावहारिक बात: अगर कोई रूट केवल ऑथ हेडर मौजूद होने पर फेल होता है, तो उसे सामान्य प्रॉक्सी विफलता के बजाय रूट-विशिष्ट विफलता के रूप में रिकॉर्ड करें। यह अंतर छोटा है, और बाद में घंटों बचाता है।