हम बैकएंड को कैसे बेंचमार्क करते हैं: एक दोहराने योग्य पद्धति

यह अंग्रेजी पाठ फ़्रेंच मूल से स्वचालित रूप से उत्पन्न हुआ था और अभी तक इसकी समीक्षा नहीं की गई है।

यह पृष्ठ स्वचालित रूप से अनुवादित किया गया था. अंग्रेजी संस्करण प्रामाणिक है.

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

अनिवार्य है

प्रकाशित, प्रतिलिपि प्रस्तुत करने योग्य प्रोटोकॉल के बाद आज तक कोई ऑराबेस प्रदर्शन परिणाम मौजूद नहीं है - यह लेख उस पद्धति का दस्तावेजीकरण करता है जिसे हम उन्हें तैयार करने के लिए लागू करेंगे, न कि पहले से प्राप्त परिणाम। रिपॉजिटरी में पहले से ही 3-स्तरीय परीक्षण सूट शामिल है: 3 क्रेट्स पर Criterion.rs माइक्रो-बेंचमार्क, 8 HTTP/वेबसॉकेट परिदृश्यों पर k6 लोड परीक्षण, और प्रतिशत गणना के साथ सीधे पोस्टग्रेज बनाम एपीआई तुलना के लिए एक पायथन स्क्रिप्ट। पूरा प्रोटोकॉल - माप अवधि, औसत के बजाय प्रतिशत, पर्यावरण अलगाव, संस्करण और दिनांक प्रकटीकरण - सत्यापित बाहरी स्रोतों पर आधारित है: पोस्टग्रेएसक्यूएल, मानदंड.आरएस, के 6 (ग्राफाना), एचडीआरहिस्टोग्राम, प्लैनेटस्केल और उत्तल। इस प्रोटोकॉल का पता लगाए बिना इस साइट पर पहले से कहीं और प्रकाशित किए गए किसी भी प्रदर्शन दावे को असत्यापित माना जाना चाहिए।

संपादकीय रुख

हम नंगे आंकड़े क्यों नहीं प्रकाशित करते?

प्रतिस्पर्धी रिस्पॉन्सिव बैकएंड के प्रकाशक कॉन्वेक्स ने सार्वजनिक रूप से खुद को डेटाबेस प्रदाताओं के बीच "बार चार्ट युद्ध" से दूर कर लिया है, जिसे इसकी तकनीकी टीम "बार चार्ट युद्ध" कहती है। उनका सूत्र सीधा है: "यह थिएटर को स्केल कर रहा है, स्केलिंग नहीं" - थिएटर को स्केल कर रहा है, वास्तविक स्केलिंग नहीं (stack.convex.dev/on-competitive-benchmarks, स्टैक टेक्निकल ब्लॉग, 23 अगस्त 2026 को एक्सेस किया गया)।

इसका केंद्रीय तर्क: एक बेंचमार्क जो स्थिरता, टोपोलॉजी या मूल्य निर्धारण मॉडल की विभिन्न गारंटी के साथ दो प्रणालियों की तुलना करता है, अक्सर एक ही चीज़ का परीक्षण नहीं करता है, भले ही वह ऐसा करने का दावा करता हो - "बेंचमार्क वास्तव में एक ही चीज़ का परीक्षण नहीं कर रहा है"। इस रिफ्लेक्स का उद्योग में एक नाम है: बेंचमार्किंग, इसकी पद्धतिगत कठोरता के बजाय इसके विपणन प्रभाव के लिए चुने गए आंकड़े को प्रकाशित करना।

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

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

निदान

अधिकांश बैकएंड बेंचमार्क को भ्रामक क्या बनाता है?

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

पहले बिंदु पर, प्लैनेटस्केल स्पष्ट रूप से अपनी हार्डवेयर समता बाधा का दस्तावेजीकरण करता है: प्रत्येक तुलनात्मक वातावरण को उसी क्लाउड क्षेत्र में संदर्भ उदाहरण के बराबर या उससे अधिक कंप्यूटिंग संसाधनों (वीसीपीयू, रैम) पर चलना चाहिए (planetscale.com/benchmarks, "टेलीस्कोप" पद्धति, 23 अगस्त, 2026 को एक्सेस किया गया)। इस अनुशासन के बिना, विलंबता अंतराल बस एक बड़ी मशीन को प्रतिबिंबित कर सकता है - तेज़ वास्तुकला को नहीं।

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

दूसरे बिंदु पर, जाल को समन्वित चूक कहा जाता है। एचडीआरहिस्टोग्राम, गिल टेने द्वारा बनाई गई विलंबता माप पर संदर्भ परियोजना, इसे इस तरह से समझाती है: जब एक लोड जनरेटर अगले एक (बंद लूप) को भेजने से पहले अनुरोध की प्रतिक्रिया की प्रतीक्षा करता है, तो एक सेवा विराम स्वचालित रूप से ठहराव के दौरान भेजे गए अनुरोधों की संख्या को कम कर देता है - और इसलिए उच्च विलंबता माप की संख्या दर्ज की जाती है (github.com/HdrHistogram/HdrHistogram, 23 अगस्त 2026 को एक्सेस किया गया)। परियोजना एक ठोस और परिमाणित उदाहरण देती है: एक काल्पनिक प्रणाली पर जो 200 सेकंड के लिए हर 10 एमएस में अपनी विलंबता का नमूना लेती है, परीक्षण के बीच में 100 सेकंड का एक ठहराव, बिना किसी सुधार के, एक हिस्टोग्राम उत्पन्न करने के लिए पर्याप्त है, जहां लगभग 99.99% प्रतिक्रियाएं 1 एमएस के अंतर्गत फिट होती हैं - भले ही वास्तविक समय का आधा हिस्सा इस एकल विराम में बीत चुका हो।

क्लासिक जाल

एक बंद-लूप लोड परीक्षण जो पिछली प्रतिक्रिया प्राप्त करने के बाद ही अनुरोध भेजता है, व्यवस्थित रूप से लंबे ठहराव को कम दर्शाता है। यह जो p99 प्रदर्शित करता है वह वास्तविक उपयोगकर्ता द्वारा अनुभव की गई वास्तविकता से बेहतर हो सकता है - इसलिए नहीं कि सिस्टम तेज़ है, बल्कि इसलिए क्योंकि माप प्रोटोकॉल रुकने के दौरान प्रश्न भेजना "भूल गया"।

आंकड़े

औसत झूठ क्यों है: p50, p95, p99

एक औसत विलंबता उत्कृष्ट लग सकती है जब बीस अनुरोधों में से एक को पांच गुना अधिक समय लगता है। यह वही है जो प्रतिशतक प्रकट करता है और औसत संरचनात्मक रूप से क्या छुपाता है।

यांत्रिक रूप से, प्रतिशतक के बारे में कुछ भी रहस्यमय नहीं है: सभी मापी गई विलंबताओं को आरोही क्रम में क्रमबद्ध करें, फिर संबंधित स्थिति में मान लें। 1000 क्रमबद्ध प्रश्नों में से, p50 500वां मान है, p95 950वां, p99 990वां। 1000 के बीच एक असामान्य रूप से धीमा अनुरोध पी99 को स्थानांतरित करने के लिए पर्याप्त है - यह वास्तव में दुर्लभ मामलों के प्रति इसकी संवेदनशीलता है जो इसे उपयोगी बनाती है, जहां इस अलग अनुरोध का औसत पर लगभग कोई प्रभाव नहीं पड़ता है।

टेल्टेल संकेत: पाठ रिपोर्ट जो pgbench - आधिकारिक PostgreSQL बेंचमार्क टूल - डिफ़ॉल्ट रूप से प्रदर्शित होती है, एक औसत और एक मानक विचलन देती है, प्रतिशत नहीं (postgresql.org/docs/current/pgbench.html, 23 अगस्त 2026 को एक्सेस किया गया)। इसका आधिकारिक दस्तावेज़ यह भी चेतावनी देता है: "कभी भी किसी ऐसे परीक्षण पर विश्वास न करें जो केवल कुछ सेकंड तक चलता है" - उस परीक्षण पर कभी विश्वास न करें जो केवल कुछ सेकंड तक चलता है, जो चुने हुए मीट्रिक के साथ-साथ अवधि पर भी उतना ही लागू होता है।

k6, लोड टूल जिसे हम अपने सुइट के लेवल 2 के लिए उपयोग करते हैं, इसे प्रतिशत में व्यक्त थ्रेसहोल्ड के साथ हल करता है: p(95)<500 सिंटैक्स एक पास/असफल मानदंड को परिभाषित करता है - 95% अनुरोधों को 500 एमएस के भीतर जवाब देना होगा - सीधे परीक्षण कॉन्फ़िगरेशन में (grafana.com/docs/k6, 23 अगस्त को परामर्श दिया गया, 2026).

p50 (माध्यिका)	आधी क्वेरीज़ इस मान से तेज़ हैं	वितरण पूँछ को पूरी तरह छुपा देता है
p95	20 में से 1 प्रश्न धीमा है	वह क्षेत्र जहां सबसे पहले असंतुष्ट उपयोगकर्ता दिखाई देते हैं
p99	100 में से 1 क्वेरी धीमी है	यदि प्रोटोकॉल खराब तरीके से डिज़ाइन किया गया है तो समन्वित चूक के प्रति सबसे संवेदनशील

कोड में चेक किया गया

3 बेंचमार्क स्तर पहले से ही हमारे भंडार में मौजूद हैं

वास्तविक उपकरणों के बिना किसी पद्धति को प्रकाशित करना रंगमंच का ही दूसरा रूप होगा। ऑराबेस रिपॉजिटरी में benchmarks/ फ़ोल्डर में पहले से ही एक 3-स्तरीय सुइट है, जो इसकी संरचना में सार्वजनिक सुपाबेस पद्धति से प्रेरित है - उपकरण मौजूद हैं, मापा और दिनांकित परिणाम अभी तक मौजूद नहीं हैं।

परीक्षण स्तर

माइक्रो, HTTP लोड, तुलना

बेंचमार्क क्रेट

आभा-क्रिप्टो, आभा-डीबी-एडेप्टर, आभा-कोर

K6 स्क्रिप्ट्स

7 को मेकफ़ाइल से जोड़ा गया, 1 प्रतीक्षा में

स्तर 1 - माइक्रो-बेंचमार्क मानदंड.rs

कार्गो कार्यक्षेत्र के तीन क्रेट्स में समर्पित सीपीयू-बाउंड बेंचमार्क हैं: aura-crypto (आर्गन2 हैश, JWT HS256 - पोस्टग्रेस्ट, एईएस-जीसीएम एन्क्रिप्शन के लिए पीढ़ी, सत्यापन और हस्ताक्षर), aura-db-adapters (पोस्टग्रेस्ट प्रारूप में पार्सिंग फिल्टर और select - eq., gte., in.(), संबंध एंबेड), और aura-core (JSON क्रमांकन, schema_nameरिज़ॉल्यूशन, UUID सत्यापन)।

libs/aura-crypto/benches/crypto_bench.rsrust

// भंडार से वास्तविक उद्धरण
let mut group = c.benchmark_group("jwt/hs256");

group.bench_function("generate", |b| {
    b.iter(|| jwt::generate_access_token(
        black_box(user_id), black_box(project_id),
        black_box("authenticated"), black_box(SECRET),
    ))
});

group.bench_function("validate", |b| {
    b.iter(|| jwt::validate_token(black_box(&token), black_box(SECRET)))
});

aura-db-adapters विशेष रूप से PostgREST प्रारूप प्रश्नों को पार्स करने की लागत को मापता है - फ़िल्टर के लिए चार मामले (simple_4, complex_10, or_group, in_large_50 50 मानों के साथ) और select के लिए चार (एकल कॉलम, *, एक संबंध एंबेड, पांच एंबेड)। यह वैश्विक लोड परीक्षण में अदृश्य प्रकार की लागत है: एक जटिल or.(...) फ़िल्टर के विश्लेषण पर एक प्रतिगमन कम उपयोग किए गए एंडपॉइंट के पी 95 में लगभग कुछ भी नहीं बदलेगा, लेकिन उच्च ट्रैफ़िक वाले एंडपॉइंट पर मापने योग्य हो जाएगा - इसलिए केवल स्तर 2 पर निर्भर रहने के बजाय इसे माइक्रो-बेंचमार्क में अलग करने में रुचि है।

aura-core एक अलग दृष्टिकोण अपनाता है: कच्चे समय को मापने के बजाय, यह गेटवे और सेवाओं के बीच आदान-प्रदान किए गए आंतरिक NatsRequest/NatsResponse संदेशों के JSON क्रमबद्धता और अक्रमांकन पर थ्रूपुट (Throughput::Bytes) को मापता है - तीन यथार्थवादी पेलोड आकार (न्यूनतम अनुरोध, JSON बॉडी नेस्टेड के साथ एक अनुरोध, एक 50-लाइन सूची प्रतिक्रिया) के साथ।

libs/aura-core/benches/core_bench.rsrust

group.throughput(Throughput::Bytes(
    serde_json::to_vec(&small).unwrap().len() as u64
));
group.bench_function("NatsRequest/small", |b| {
    b.iter(|| serde_json::to_vec(black_box(&small)).unwrap())
});

Criterion.rs केवल एक लूप का समय नहीं है। यह पहले सीपीयू/ओएस कैश को भरने के लिए वार्म-अप चरण चलाता है, टुकी की विधि के एक संशोधित संस्करण के साथ आउटलेर्स का पता लगाता है (डेटासेट से उन्हें बाहर किए बिना), बड़ी संख्या में पुन: नमूना किए गए नमूनों पर बूटस्ट्रैपिंग द्वारा विश्वास अंतराल की गणना करता है, और एक विन्यास योग्य शोर सीमा के साथ छात्र के सांख्यिकीय परीक्षण द्वारा दो रनों के बीच प्रदर्शन प्रतिगमन का पता लगाता है - आमतौर पर ±1% - उन विविधताओं को अनदेखा करने के लिए जो सांख्यिकीय रूप से महत्वपूर्ण नहीं हैं (bheisler.github.io/criterion.rs/book/analyse.html, 23 अगस्त 2026 को एक्सेस किया गया)।

स्थानीय रूप से प्रतिलिपि प्रस्तुत करने योग्य

प्रत्येक मानदंड रन target/criterion/ में एक विस्तृत HTML रिपोर्ट तैयार करता है - वितरण, प्रतिगमन ग्राफ़, पिछले रन की तुलना में। यह रिश्ता है, न कि केवल एक टर्मिनल लाइन, जिसे एक गंभीर कार्यप्रणाली द्वारा पुनर्जीवित करना संभव बनाना चाहिए।

स्तर 2 - k6 लोड परीक्षण

आठ k6 स्क्रिप्ट डेटा प्लेन साइड पर गेटवे को कवर करती हैं: health (विलंबता बेसलाइन), auth-flow (रजिस्टर → लॉगिन → रिफ्रेश → लॉगआउट), crud-read और crud-write, storage (अपलोड/डाउनलोड), realtime-ws, breakpoint (विफलता तक लोड में वृद्धि) और supabase-compare। सात को एक समर्पित Makefile लक्ष्य से जोड़ा गया है - supabase-compare.js रिपॉजिटरी में मौजूद है, लेकिन अभी तक कोई लक्ष्य नहीं है, ऐसी स्थिति है कि यह लेख इसे छिपाने के बजाय दस्तावेज़ के रूप में प्रस्तुत करता है।

benchmarks/k6/scenarios/crud-read.jsjavascript

export const options = {
  scenarios: {
    crud_read: {
      executor: 'ramping-vus',
      startVUs: 10,
      stages: [
        { duration: '30s', target: 50 },
        { duration: '1m', target: 200 },
        { duration: '30s', target: 0 },
      ],
    },
  },
  thresholds: THRESHOLDS_READ,
}

साझा कॉन्फ़िगरेशन प्रत्येक ऑपरेशन प्रकार के लिए थ्रेसहोल्ड को परिभाषित करता है। ये पास/असफल मानदंड हैं जिन्हें परीक्षण हर बार चलने पर जांचता है - पहले से ही मापे गए परिणाम नहीं:

पढ़ना (प्राप्त करें)	पी95 <500 एमएस · पी99 <1000 एमएस	कॉन्फ़िगरेशन k6 (बेंचमार्क/k6/lib/config.js)
लेखन (पोस्ट/पैच)	पी95 <300 एमएस · पी99 <1000 एमएस	कॉन्फ़िग k6
प्रामाणिक (लॉगिन/रीफ्रेश)	पी95 <300 एमएस · पी99 <1000 एमएस	कॉन्फ़िग k6
भंडारण (अपलोड/डाउनलोड)	पी95 <500 एमएस · पी99 <2000 एमएस	कॉन्फ़िग k6
त्रुटि दर, सभी परिदृश्य	< 1 %	कॉन्फ़िग k6

इस लेख को लिखते समय एक विसंगति पाई गई

benchmarks/ फ़ोल्डर में README.md < 200ms ("सुपाबेस SLO") पर p95 की रीडिंग थ्रेशोल्ड का दस्तावेजीकरण करता है, जबकि वास्तव में benchmarks/k6/lib/config.js में लागू थ्रेशोल्ड - जिस पर परीक्षण चलता है - p(95)<500है। दोनों फ़ाइलें एक दूसरे से ली गई हैं। यह एक ठोस उदाहरण है, जो इस लेख के लिए स्रोत कोड को पढ़ते समय पाया गया, कि क्यों एक प्रोटोकॉल में दो स्थानों पर दस्तावेज किए जाने के बजाय सत्य का एक ही संस्करण वाला स्रोत होना चाहिए: इसके बिना, यहां तक कि एक टीम जो कठोर होने की कोशिश करती है वह विरोधाभासी थ्रेसहोल्ड प्रकाशित करती है।

लेवल 3 - डायरेक्ट पोस्टग्रेएसक्यूएल बनाम एपीआई तुलना

एक पायथन स्क्रिप्ट (direct_vs_api.py) एक ही ऑपरेशन पर HTTP कॉल के लिए प्रत्यक्ष psycopg2 अनुरोधों की तुलना करके गेटवे + सेवा परत के वास्तविक ओवरहेड को मापता है - सूची, आईडी द्वारा एक बार पढ़ा गया, फ़िल्टर किया गया और क्रमबद्ध पढ़ा गया। प्रत्येक माप समयबद्ध लूप से पहले 10 पुनरावृत्तियों के वार्म-अप का अनुसरण करता है, फिर प्रति सेकंड संचालन में औसत, पी 50, पी 95, पी 99 और थ्रूपुट की गणना करता है।

benchmarks/comparison/direct_vs_api.pypython

def percentile(data, p):
    k = (len(data) - 1) * (p / 100)
    f = int(k)
    c = f + 1
    if c >= len(data):
        return data[f]
    return data[f] + (k - f) * (data[c] - data[f])

एक दूसरी स्क्रिप्ट (aurabase_vs_supabase.py) एक स्थानीय सुपाबेस उदाहरण (डिफ़ॉल्ट रूप से सुपाबेस सीएलआई, localhost:54321) के साथ आमने-सामने की तुलना में समान वार्मअप और प्रतिशतक गणना तर्क लागू करती है - एक ही मशीन, दोनों के लिए एक ही स्थानीय नेटवर्क, बिल्कुल पर्यावरण समता अनुशासन जिसे प्लैनेटस्केल अपनी तुलना के लिए दस्तावेज करता है।

एक ऑर्केस्ट्रेशन स्क्रिप्ट (collect_baseline.sh, लक्ष्य bench-baseline का Makefile) तीन स्तरों को जोड़ती है - 3 क्रेट्स पर मानदंड, k6 परिदृश्यों का एक उपसमूह (health और crud-read आज, सभी 8 अभी तक नहीं), फिर पायथन तुलना - और लॉग, JSON और मानदंड HTML रिपोर्ट को अद्वितीय टाइमस्टैम्प वाले फ़ोल्डर में लिखता है: benchmarks/results/AAAAMMJJ_HHMMSS/। यह बिल्कुल दिनांकित प्रकटीकरण का प्रतिबिंब है, एक एकल प्रतिलिपि प्रस्तुत करने योग्य रन में, जिसे निम्नलिखित अनुभाग एक पूर्ण प्रोटोकॉल में औपचारिक बनाता है।

क्रियाविधि

किसी आंकड़े को प्रकाशित करने से पहले हम प्रोटोकॉल लागू करेंगे

आठ प्रतिबद्धताएँ, प्रत्येक एक मान्यता प्राप्त तृतीय-पक्ष टूल या प्रोजेक्ट द्वारा पहले से ही प्रलेखित अभ्यास में शामिल हैं - इस अवसर के लिए आविष्कार नहीं किया गया है।

प्रीहीटिंग माप से अलग। Criterion.rs समय से पहले CPU/OS कैश भरता है; pgbench स्पष्ट रूप से अनुशंसा करता है कि कभी भी कुछ सेकंड तक चलने वाली दौड़ पर विश्वास न करें।
निश्चित अवधि, पुनरावृत्तियों की निश्चित संख्या नहीं। एक लोड को अभिसरण करने के लिए समय की आवश्यकता होती है - यह stages k6 और pgbenchके -T ध्वज की भूमिका है।
प्रतिशत, कभी भी औसत नहीं - और यदि लोड जनरेटर एक बंद लूप में संचालित होता है तो समन्वित चूक पर सक्रिय सतर्कता।
पर्यावरण को विस्तार से प्रलेखित किया गया है: परीक्षण की गई सेवा का git कमिट, PostgreSQL का संस्करण, हार्डवेयर विनिर्देश, लोड टूल का संस्करण। प्लैनेटस्केल ठीक इसी कारण से अपने सटीक टीपीसीसी मापदंडों (TABLES=20, SCALE=250, ~500 जीबी) का दस्तावेजीकरण करता है - इन विवरणों के बिना, कोई भी रन को पुन: उत्पन्न नहीं कर सकता है।
टाइमस्टैम्प्ड और संस्करणित परिणाम, मार्केटिंग पेज पर कभी भी एक भी नंबर बिना तारीख के अंकित नहीं होता। वर्तमान टूलींग पहले से ही एक दिनांकित फ़ाइल में लिखी हुई है; इस रिफ्लेक्स को किसी भी सार्वजनिक रूप से प्रकाशित माप में विस्तारित करना आवश्यक होगा, होस्टिंग क्षेत्र को किसी भी अन्य पर्यावरणीय चर की तरह प्रलेखित किया जाएगा (EU होस्टिंग संप्रभुतापर हमारा गाइड देखें, जैसे ही कोई आंकड़ा किसी दिए गए क्षेत्र पर निर्भर करता है, प्रासंगिक हो जाता है)।
स्क्रिप्ट और कच्चा डेटा समग्र परिणाम के साथ प्रकाशित किया गया, न कि केवल अंतिम औसत के साथ। प्लैनेटस्केल पाठकों को एक समर्पित पते पर पद्धतिगत त्रुटि की रिपोर्ट करने के लिए भी आमंत्रित करता है - एक आसन जो हमें स्वस्थ लगता है और जिसे हम फिर से शुरू करना चाहते हैं।
विलंबता के साथ-साथ विज्ञापित थ्रूपुट, केवल एक या दूसरे को नहीं। एक सिस्टम में कम लोड पर उत्कृष्ट विलंबता हो सकती है और संगामिति बढ़ने पर थ्रूपुट में गिरावट आ सकती है - यह वही है जो हमारे k6 सुइट के breakpoint परिदृश्य (स्केल-टू-क्रैश) को प्रकट करने के लिए डिज़ाइन किया गया है, और मानदंड का Throughput::Bytes माइक्रोबेंचमार्क माप फ़ंक्शन स्तर पर क्या कैप्चर करता है।
सुधार की घोषणा करने से पहले महत्वपूर्ण अंतर। दो रनों के बीच कुछ प्रतिशत का अंतर वास्तविक लाभ के बजाय माप शोर हो सकता है - Criterion.rs इसे प्रतिगमन या सुधार के रूप में अर्हता प्राप्त करने से पहले एक संभावना की गणना करता है कि देखा गया अंतर संयोग के कारण है। इस सत्यापन के बिना, एक पृथक आंकड़ा, केवल एक सांख्यिकीय उपाख्यान है।

संपादकीय प्रतिबद्धता

हम क्या नहीं करेंगे

यह सूची उपरोक्त सकारात्मक प्रोटोकॉल जितनी ही मायने रखती है।

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

एक ठोस उदाहरण, जिसे पहले ही आंतरिक रूप से ठीक कर लिया गया है

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

repeatable

किसी भी बैकएंड को बेंचमार्क करने के लिए न्यूनतम प्रोटोकॉल

यह प्रोटोकॉल किसी विशिष्ट ऑराबेस टूल पर निर्भर नहीं है - आप इसे आज ही अपने एपीआई पर लागू कर सकते हैं।

टूल से पहले लोड सेट करें: आपके एप्लिकेशन के लिए केवल-पढ़ें, लिखें, यथार्थवादी मिश्रण - किसी अन्य प्रोजेक्ट से कॉपी किया गया सामान्य अनुपात नहीं।
प्रीहीटिंग चरण को मापने के चरण से स्पष्ट रूप से अलग करें।
परीक्षण को काफी देर तक चलाएँ - मिनटों में, सेकंडों में नहीं।
प्रतिशतक (p50/p95/p99) में मापें, अकेले औसत पर कभी नहीं।
सत्यापित करें कि आपका लोड जनरेटर बंद लूप में नहीं है, या विश्लेषण में समन्वय चूक को ठीक करें।
परीक्षण के तहत पर्यावरण को अलग करें - कोई शोर-शराबा करने वाला पड़ोसी नहीं, कोई प्रतिस्पर्धी पृष्ठभूमि कार्य नहीं।
परीक्षण किया गया संस्करण, दिनांक, हार्डवेयर विनिर्देश और स्क्रिप्ट प्रकाशित करें - न कि केवल अंतिम परिणाम।

नंगे पोस्टग्रेज बेस पर, यह प्रोटोकॉल एक कमांड pgbench लेता है - 20 समवर्ती क्लाइंट, 5 मिनट के लिए 4 थ्रेड्स पर वितरित, हर 10 सेकंड में एक प्रगति रिपोर्ट के साथ:

terminalbash

# परीक्षण डेटासेट प्रारंभ करें (स्केल फ़ैक्टर >=ग्राहकों की संख्या)
pgbench -i -s 50 ma_base

# -सी समवर्ती क्लाइंट, -जे थ्रेड, -टी अवधि सेकंड में, -पी रिपोर्टिंग अंतराल
pgbench -c 20 -j 4 -T 300 -P 10 ma_base

औजार

संदर्भ उपकरण, स्तर के अनुसार

पांच उपकरण, प्रत्येक स्टैक के एक अलग स्तर के लिए उपयुक्त - कोई भी दूसरे को प्रतिस्थापित नहीं करता है।

माइक्रोफ़ोन (फ़ंक्शन)	मानदंड.आरएस	शुद्ध सीपीयू, बूटस्ट्रैप आँकड़े
एसक्यूएल क्वेरी	पीजीबेंच	टीपीसी-बी-जैसे लेनदेन, टीपीएस और विलंबता
HTTP/WS लोड	k6 (ग्राफाना)	प्रतिशत, उत्तीर्ण/असफल सीमाएँ
बड़े पैमाने पर ओएलटीपी	सिसबेंच + टीपीसीसी (टेलीस्कोप पद्धति)	क्यूपीएस, प्रति प्रदर्शन लागत
मापन सुधार	एचडीआरहिस्टोग्राम	समन्वित चूक के लिए क्षतिपूर्ति

अक्सर पूछे जाने वाले प्रश्नों

पूछे जाने वाले प्रश्न

ऑराबेस अभी तक बेंचमार्क संख्याएँ प्रकाशित क्यों नहीं कर रहा है?+

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

पी95 या पी99 प्रतिशतक क्या है, और औसत क्यों नहीं?+

पी95 प्रतिक्रिया समय है जिसके नीचे 95% अनुरोध पाए जाते हैं - इसलिए 20 में से 1 अनुरोध धीमा है। पी99 इस सीमा को 100 में 1 अनुरोध तक धकेलता है। औसत इन धीमे अनुरोधों को छुपाता है क्योंकि यह उन्हें तेज़ अनुरोधों के द्रव्यमान में पतला कर देता है; प्रतिशत वितरण के उस हिस्से को अलग करता है जिसे उपयोगकर्ता वास्तव में नोटिस करते हैं।

"समन्वित चूक" क्या है?+

यह एचडीआरहिस्टोग्राम प्रोजेक्ट द्वारा वर्णित एक माप पूर्वाग्रह है: जब एक लोड टूल अगले अनुरोध (बंद लूप) को भेजने से पहले एक अनुरोध की प्रतिक्रिया की प्रतीक्षा करता है, तो एक सेवा विराम यांत्रिक रूप से इस ठहराव के दौरान दर्ज किए गए धीमे अनुरोधों की संख्या को कम कर देता है। अंतिम परिणाम वास्तविक उपयोगकर्ता द्वारा अनुभव की गई विलंबता से कहीं बेहतर विलंबता दिखा सकता है।

क्या हम इन परीक्षणों को स्वयं पुन: प्रस्तुत कर सकते हैं?+

यहां वर्णित प्रोटोकॉल - प्रतिशतक, अलग प्रीहीटिंग, दस्तावेजित वातावरण, दिनांकित परिणाम - सार्वजनिक उपकरण (k6, pgbench, Criterion.rs, sysbench) के साथ किसी भी एपीआई पर लागू होता है। आंतरिक ऑराबेस टूलिंग (बेंचमार्क/रिपॉजिटरी फ़ोल्डर) वर्तमान में विकास के लिए उपयोग किया जाता है और अभी तक इसे एक-क्लिक सार्वजनिक सूट के रूप में पैक नहीं किया गया है। अपनी स्वयं की k6 स्क्रिप्ट के साथ ऑराबेस एपीआई पर अपने स्वयं के लोड का परीक्षण करने के लिए एक प्रोजेक्ट बनाएं।

मापे गए प्रतिशतक और SLA सीमा के बीच क्या अंतर है?+

एक प्रतिशतक (पी95, पी99) वास्तविक माप पर तथ्य के बाद गणना किया गया एक आँकड़ा है। एक SLA सीमा (या k6 सीमा जैसे p(95)<500) पहले से निर्धारित एक लक्ष्य है, जिसे परीक्षण पास/असफल मोड में सत्यापित करता है। दोनों को भ्रमित करने से एक अप्राप्त उद्देश्य को प्राप्त परिणाम के रूप में प्रस्तुत किया जाता है - यही वह अंतर है जिसे इस प्रोटोकॉल को प्रत्येक प्रकाशित आंकड़े के साथ स्पष्ट रखने की आवश्यकता है।

विलंबता के अतिरिक्त थ्रूपुट को क्यों मापें?+

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