रिस्पॉन्स साइज़ एनालाइज़र

सर्वर सहायता परफ़ॉर्मेंस

कोई सार्वजनिक URL fetch करें या बॉडी चिपकाएँ और transfer साइज़, gzip/brotli अनुमान, हेडर का बोझ तथा यह देखें कि कौन-से JSON फ़ील्ड सबसे ज़्यादा बाइट लेते हैं।

गोपनीयता: जहाँ संभव हो प्रोसेसिंग आपके ब्राउज़र में होती है। नेटवर्क जाँच मुत्क़न बैकएंड के माध्यम से की जाती है और संग्रहीत नहीं की जाती।

परफ़ॉर्मेंस टेस्टिंग क्या है?

परफ़ॉर्मेंस टेस्टिंग मापती है कि सिस्टम निर्धारित वर्कलोड में कैसे व्यवहार करता है: रिस्पॉन्स टाइम (आमतौर पर औसत नहीं, 95वाँ पर्सेंटाइल), थ्रूपुट (रिक्वेस्ट प्रति सेकंड) और एरर रेट, साथ में CPU, मेमोरी और डेटाबेस की संतृप्ति पर नज़र। लोड टेस्टिंग अपेक्षित ट्रैफ़िक इस्तेमाल करती है, स्ट्रेस टेस्टिंग उससे आगे जाकर टूटने का बिंदु खोजती है, सोक टेस्टिंग घंटों तक लोड रखकर लीक उजागर करती है, और स्पाइक टेस्टिंग अचानक उछाल से रिकवरी जाँचती है।

गाइड पढ़ें: परफ़ॉर्मेंस टेस्टिंग क्या है?

रिस्पॉन्स साइज़ एनालाइज़र कैसे इस्तेमाल करें

  1. स्रोत चुनें: रिस्पॉन्स बॉडी चिपकाएँ (जो आपके ब्राउज़र में ही रहती है) या कोई सार्वजनिक URL डालें।
  2. चाहें तो रिस्पॉन्स हेडर भी चिपकाएँ, ताकि हेडर का बोझ और Content-Type शामिल हो जाए।
  3. "Analyze" दबाकर कच्चा, minified, gzip और brotli साइज़ साथ-साथ देखें।
  4. "सबसे बड़े JSON फ़ील्ड" खोलकर वे प्रॉपर्टी ढूँढें जिन्हें छाँटना या पेजिनेट करना फ़ायदेमंद है।
  5. सुझाव लागू करें (compression, minification, sparse fieldset) और दोबारा जाँचें।

रिस्पॉन्स साइज़ एनालाइज़र की खूबियाँ

  • बॉडी को निजी तौर पर चिपकाएँ, या relay के ज़रिये कोई सार्वजनिक URL fetch करें
  • कच्चे बाइट, अक्षर, हेडर का बोझ और कुल transfer साइज़
  • बाइट एन्ट्रॉपी और दोहराव से gzip तथा brotli साइज़ के अनुमान (कुछ भी अपलोड किए बिना)
  • JSON ढाँचे का भार: minified साइज़, whitespace का हिस्सा, key की संख्या और गहराई
  • उन JSON फ़ील्ड की रैंकिंग जो सबसे ज़्यादा बाइट जोड़ते हैं
  • काम के सुझाव: compression चालू करें, minify करें, पेजिनेट करें या फ़ील्ड कम करें

रिस्पॉन्स साइज़ एनालाइज़र का उदाहरण

सुंदर ढंग से फ़ॉर्मेट की गई product सूची

इनपुट:

{
  "data": [ { "id": 1, "name": "Sample product 1", "description": "…" }, … ],
  "meta": { "page": 1, "total": 6 }
}

आउटपुट:

Body: 3.9 KB · Headers: 142 B · Total: 4.0 KB
gzip (est.): 1.1 KB (72% smaller) · brotli (est.): 0.9 KB
JSON minified: 3.1 KB (20% whitespace)
Largest fields: data 97% · data[0].description 15% · data[0].images 8%

रिस्पॉन्स साइज़ एनालाइज़र के बारे में अक्सर पूछे जाने वाले सवाल

gzip साइज़ का अनुमान कैसे लगता है?

स्थानीय रूप से, बॉडी की बाइट एन्ट्रॉपी और उसमें मौजूद दोहराव से — ब्राउज़र में कोई compressor नहीं चलता। असली gzip/brotli नतीजे आमतौर पर इस अनुमान के ±15% के भीतर रहते हैं।

हेडर का बोझ किसे गिना जाता है?

हर हेडर पंक्ति ("Name: value" और CRLF)। बड़ी cookie और लंबे कस्टम हेडर हर रिक्वेस्ट व रिस्पॉन्स के साथ जाते हैं, इसलिए 2 KB की JSON बॉडी पर 4 KB का हेडर ब्लॉक ठीक करने लायक़ है।

सबसे बड़े JSON फ़ील्ड कैसे चुने जाते हैं?

टूल हर प्रॉपर्टी को serialise करके UTF-8 बाइट के हिसाब से रैंक करता है, जिसमें नेस्टेड पाथ और ऐरे के शुरुआती आइटम भी शामिल हैं, ताकि आप देख सकें कि पेलोड पर किन फ़ील्ड का दबदबा है।

क्या fetch मोड compressed बॉडी डाउनलोड करता है या कच्ची?

relay identity encoding माँगता है ताकि कच्चा साइज़ मापा जा सके; origin का Content-Encoding हेडर बताता है कि वह सामान्य रूप से compression करता है या नहीं।

क्या मेरी चिपकाई हुई बॉडी कहीं अपलोड होती है?

नहीं। paste मोड पूरी तरह आपके ब्राउज़र में चलता है; सिर्फ़ fetch मोड में URL relay को भेजा जाता है।

तकनीकी नोट्स

compression का अनुमान बॉडी की order-0 Shannon एन्ट्रॉपी और दोहराई गई 8-अक्षरी विंडो के हिस्से को मिलाकर लगाया जाता है, जो LZ77 back-reference का सस्ता अनुमान है। यह गणना नियतात्मक है, पहले 256 KB पर चलती है और फिर पूरी लंबाई के अनुपात में बढ़ा दी जाती है।

फ़ील्ड का भार हर प्रॉपर्टी को JSON.stringify से serialise करके UTF-8 बाइट गिनकर निकाला जाता है, जिसमें key और separator भी शामिल हैं। ऐरे को पूरा एक इकाई मानकर मापा जाता है और नेस्टेड पाथ के लिए उनके पहले 20 ऑब्जेक्ट आइटम खंगाले जाते हैं।

संदर्भ

  • Apache JMeter User's ManualApache Software FoundationJMeter से लोड टेस्ट कैसे बनाएँ, पैरामीटराइज़ करें और चलाएँ, और उसके लिसनर व रिपोर्ट कैसे पढ़ें।
  • Release It! Second Edition: Design and Deploy Production-Ready Software (Michael T. Nygard)The Pragmatic Bookshelf · 2018स्थिरता पैटर्न — टाइमआउट, सर्किट ब्रेकर, बल्कहेड, बैक-प्रेशर — और वे विफलता के तरीके जिन्हें लोड टेस्टिंग खोजने के लिए है।
  • Site Reliability Engineering: How Google Runs Production SystemsGoogle / O'Reilly Media · 2016सर्विस लेवल ऑब्जेक्टिव, एरर बजट, "चार गोल्डन सिग्नल" की निगरानी और ओवरलोड संभालना — लचीलेपन का परिचालन पक्ष।