सिंक प्रदर्शन और सर्वर के प्रति शिष्टाचार
यह पेज WCPOS v1.10.0 में पेश किए गए सिंक इंजन का वर्णन करता है। इंजन यांत्रिक रूप से कैसे काम करता है, यह जानने के लिए सिंक इंजन कैसे काम करता है से शुरू करें।
अधिकांश WCPOS स्टोर साझा PHP होस्टिंग पर चलते हैं: गिनती के कुछ PHP वर्कर, हर REST अनुरोध पर पूरा WordPress बूटस्ट्रैप, और ऐसे सुरक्षा प्लगइन जो अनुरोधों के झोंकों पर दर सीमित लगाते हैं। जिन अनुरोधों को क्लाइंट मुफ़्त मान लेता है, वे स्टोरफ़्रंट को धीमा करते हैं, रेट लिमिटर चालू कर देते हैं और कैशियर के अपने ट्रैफ़िक से होड़ करते हैं — और यह सब आपके हर काउंटर तथा हर ब्राउज़र टैब से गुणा हो जाता है।
v1.10.0 सिंक इंजन इसे बाद में सोचने वाली बात नहीं, बल्कि एक डिज़ाइन बाधा मानता है: व्यापारी की होस्टिंग की रक्षा करना सिंक इंजन के काम का हिस्सा है। यह पेज उन नियमों की व्याख्या करता है जिनका इंजन पालन करता है, और उनके पीछे की मापों की भी।
चार स्थायी नियम
इंजन का हर निर्धारित सिंक व्यवहार चार अपरिवर्तनीय नियमों से संचालित होता है:
- लागत इस बात के अनुसार बढ़ती है कि क्या बदला, कभी कैटलॉग के आकार के अनुसार नहीं। किसी भी थोक फ़ेच से पहले हमेशा एक सस्ता डाइजेस्ट या शॉर्ट-सर्किट जाँच होती है। बिना बदले 50,000 उत्पादों वाले स्टोर को सिंक में रखने की लागत लगभग उतनी ही होती है जितनी बिना बदले 500 उत्पादों वाले स्टोर की।
- कोई असीमित फ़ैन-आउट नहीं। हर पृष्ठभूमि लेन एक प्रति-रन अनुरोध सीमा घोषित करती है, जिसे स्वचालित परीक्षण लागू करते हैं। बड़े कार्य पुनः-आरंभ योग्य कर्सर के साथ सीमाबद्ध बैचों में चलते हैं — कोई स्वीप विस्फोट करने के बजाय अपनी समय-सारणी में फैल जाता है।
- रखरखाव कभी कैशियर के रास्ते में नहीं आता। जो अनुरोध किसी काउंटर को बिक्री के लिए तैयार करते हैं, वे पहले चलते हैं; अखंडता ऑडिट और पृष्ठभूमि प्राइम उसके बाद, निष्क्रिय समय में चलते हैं।
- दबाव में सबसे पहले रखरखाव पीछे हटता है। जब आपका सर्वर परेशानी का संकेत देता है, तो कैशियर से जुड़ी किसी भी चीज़ को छूने से पहले इंजन अपना ही पृष्ठभूमि कार्य धीमा कर देता है।
सिंकिंग की आपके सर्वर पर क्या लागत आती है
स्थिर-स्थिति लागत सिंक प्रीसेट से तय होती है, जिसे स्टोर हेल्थ → प्रदर्शन में प्रति डिवाइस चुना जाता है:
| प्रीसेट | जाँच अंतराल | प्रति अनुरोध रिकॉर्ड | प्रतिदिन नाममात्र जाँचें |
|---|---|---|---|
| Eco | 5 मिनट | 25 | 288 |
| Balanced (डिफ़ॉल्ट) | 60 से | 50 | 1,440 |
| Realtime | 10 से | 75 | 8,640 |
दोनों डायल मायने रखते हैं, और साझा होस्ट पर असल लागत आमतौर पर पेज के भार से आती है — रिकॉर्ड का भारी पेज सर्वर का वास्तविक समय लेता है, और अंतराल उसे बस गुणा कर देता है। कोई भी प्रीसेट अधिकतम 100-रिकॉर्ड वाला पेज नहीं भेजता; वह केवल Custom स्लाइडर (5 से–5 मिनट अंतराल, 10–100 रिकॉर्ड) से ही पहुँच में आता है।
प्रीसेट के अलावा:
- निष्क्रिय जाँच कम खर्चीली होती है। इंजन सशर्त अनुरोध भेजता है, इसलिए बिना बदलाव वाली जाँच का उत्तर बिना बॉडी वाला एक अकेला
304 Not Modifiedहोता है — फिर भी एक अनुरोध, लेकिन बिना पेलोड और न्यूनतम सर्वर काम के साथ। - जाँचों में ±20% जिटर होता है, इसलिए रजिस्टरों का बेड़ा अपने अनुरोधों को झोंकों में तालमेल बिठाने के बजाय फैला देता है।
- निष्क्रिय काउंटर क्षय होकर 10 मिनट बिना इंटरैक्शन के धीमी लय पर चले जाते हैं और किसी भी गतिविधि पर — बारकोड स्कैन सहित — तुरंत वापस लौट आते हैं।
- पृष्ठभूमि रखरखाव सीमित है। बिना किसी विचलन वाली अखंडता जाँच में अधिक से अधिक कुछ सस्ते एग्रीगेट पेज लगते हैं और शून्य विस्तृत फ़ेच — जिन बकेट का सर्वर से मेल प्रमाणित हो जाता है, उन्हें सीधे छोड़ दिया जाता है। विचलन मिलने पर ड्रिल-डाउन प्रति रन दो तक सीमित होते हैं, और विस्फोट करने के बजाय एक संचित कर्सर से आगे बढ़ते हैं। पूरा विलोपन ऑडिट प्रति रन 11 अनुरोध पर सीमाबद्ध है, और डाइजेस्ट प्राइम प्रति रन 5 चंक पर। ये सीमाएँ कोड में घोषित हैं और CI द्वारा लागू की जाती हैं।
स्टोर हेल्थ अपना ~N अनुरोध प्रतिदिन अनुमान कॉन्फ़िगर किए गए अंतराल से निकालता है। इसे नाममात्र जाँच दर मानें, कोई अधिकतम सीमा या पूर्वानुमान नहीं: ±20% जिटर वास्तविक गिनती को किसी भी दिशा में खिसका सकता है, और 304 भी एक अनुरोध ही गिना जाता है। निष्क्रियता क्षय गिनती को केवल उन प्रीसेट के लिए घटाता है जो उसकी 60-सेकंड की न्यूनतम सीमा से तेज़ हैं; यह डिफ़ॉल्ट Balanced प्रीसेट को और धीमा नहीं करता।
जब आपका सर्वर संघर्ष कर रहा हो तो पीछे हटना
इंजन को मिलने वाली हर प्रतिक्रिया प्रति-स्टोर दबाव मॉनिटर को डेटा देती है। वह इन पर प्रतिक्रिया करता है:
- HTTP
429(तुरंत), - बार-बार आने वाली
5xxत्रुटियाँ या ट्रांसपोर्ट विफलताएँ (एक चलते हुए मिनट के भीतर तीन), - लगातार धीमापन (माध्य प्रतिक्रिया समय 2 सेकंड से ऊपर),
- एक
Retry-Afterहेडर, जो अगली जाँच के लिए कठोर न्यूनतम सीमा बन जाता है।
इनमें से कोई भी चालू होने पर इंजन अपना परिवर्तन-जाँच अंतराल एक-एक चरण करके दोगुना करता है, और रखरखाव लेन अपने रन पूरी तरह छोड़ देती हैं। कैशियर द्वारा चलाए गए अनुरोध — खोज, बारकोड लुकअप, चेकआउट — कभी थ्रॉटल नहीं किए जाते; मकसद टाले जा सकने वाले भार को हटाना है, बिक्री को धीमा करना नहीं।
रिकवरी जानबूझकर असममित है: बैक-ऑफ़ तत्काल होता है, लेकिन अंतराल लगातार दस स्वस्थ प्रतिक्रियाओं के बाद ही एक कदम नीचे आता है, ताकि अस्थिर सर्वर तेज़ और धीमी लय के बीच झूलता न रहे। दबाव की स्थिति तब भी बनी रहती है जब व्यापारी कोई तेज़ प्रीसेट चुन ले — यह सुरक्षा जो भी स्तर कॉन्फ़िगर किया गया हो उसके नीचे चलती है, और इसे बंद करने का कोई तरीका नहीं है।
डिवाइस पर प्रतिक्रियाशील बने रहना
प्रदर्शन का दूसरा आधा हिस्सा स्वयं काउंटर है — पृष्ठभूमि सिंक से UI कभी अटकनी नहीं चाहिए।
- ऑडिट इवेंट लूप को रास्ता देते हैं। अखंडता ऑडिट अपने काम को चंक में बाँटता है और चंकों के बीच रास्ता छोड़ता है, जिससे इसका सबसे लंबा निर्बाध ब्लॉक लगभग 30 ms रहता है — उस ~100 ms की सीमा से नीचे जहाँ मनुष्य अटकाव महसूस करते हैं। 10,000 लोकल उत्पादों पर मापा गया एक पूरा ऑडिट पास लगभग 68 ms की गणना लागत लेता है, जो 17+ यील्ड में बँटी होती है; 50,000 उत्पादों पर 300 ms से कम।
- भार में भी पहला परिणाम तेज़ रहता है। पहले परिणाम तक लगने वाले समय के अनुबंध CI में तय हैं, तब भी जब साथ-साथ कोई थोक अप्लाई या पूरा ऑडिट चल रहा हो — बेंचमार्क परिवेश में सामान्य कैटलॉग आकारों पर यह एकल-अंक मिलीसेकंड में रहता है।
- ऐप तक केवल दिखाई देने वाला पेज पहुँचता है। क्वेरी का काम (फ़िल्टर, सॉर्ट, पेजिनेशन) स्टोरेज परत के भीतर चलता है, इसलिए स्क्रीन अपडेट में दस हज़ार नहीं, दस पंक्तियाँ ही आती-जाती हैं।
ये आँकड़े इंजन की तय प्रदर्शन-अनुबंध सूट से आते हैं, जो CI में अलग-थलग चलती है और जिसके बजट मापी गई स्थिर स्थिति से लगभग परिमाण के एक क्रम ऊपर रखे गए हैं — ये परिमाण-स्तर की गिरावट पकड़ने के लिए बनाए गए हैं, किसी धीमे रनर पर विफल होने के लिए नहीं।
एक वास्तविक स्टोर पर सत्यापित
शिष्टाचार के नियम केवल यूनिट-टेस्ट किए हुए नहीं हैं। एक वास्तविक WordPress स्टोर पर चलने वाली लाइव एंड-टू-एंड जाँच उन अपरिवर्तनीय नियमों को सत्यापित करती है जो असली होस्टिंग पर सबसे अधिक मायने रखते हैं:
- स्टोर खुलने पर उत्पाद कैटलॉग रेंडर होने से पहले शून्य रखरखाव अनुरोध (अखंडता या डाइजेस्ट ट्रैफ़िक)।
- खुलने के बाद की रोक के पश्चात, अधिक से अधिक कुछ सस्ते एग्रीगेट पेज और दो से अधिक विस्तृत ड्रिल-डाउन नहीं।
यह परिदृश्य एक असली रिग्रेशन से बना था: ऑडिट के एक पुराने डेवलपमेंट बिल्ड में हर बार स्टोर खुलने पर, प्रति डिवाइस, ~41 अनुरोध (1.2 MB) जाते थे। उसकी जगह आए डाइजेस्ट-गेटेड डिज़ाइन ने बिना विचलन वाले ऑडिट को घटाकर उसके एग्रीगेट पेजों तक सीमित कर दिया और कुछ नहीं — इस श्रेणी के बग की रक्षा अब समीक्षा की सतर्कता से नहीं, बल्कि CI में घोषित सीमाओं से होती है।
हम क्या दावा नहीं करते
कुछ बातें यह पेज जानबूझकर नहीं कहता, क्योंकि (अभी) हमारे पास उनके लिए बचाव योग्य आँकड़े नहीं हैं:
- कोई एंड-टू-एंड "आरंभिक सिंक में X मिनट लगते हैं" आँकड़ा नहीं। आरंभिक डाउनलोड का समय भारी रूप से आपके सर्वर के प्रतिक्रिया समय और कैटलॉग के आकार पर निर्भर करता है। रिकॉर्ड लागू करने की डिवाइस-पक्ष लागत छोटी है (10,000 उत्पादों को थोक में लागू करने में 10 ms से कम गणना लगती है); नेटवर्क और सर्वर ही हावी रहते हैं।
- कोई "v1.9 से X% तेज़" दावा नहीं। दोनों की वास्तुकलाएँ इतनी अलग हैं कि कोई एक तुलनात्मक संख्या जानकारी देने से ज़्यादा भ्रमित करेगी। संरचनात्मक अंतर v1.10.0 में क्या बदला में दिए गए हैं।
- ऊपर दिए गए बेंचमार्क आँकड़े इंजन के परीक्षण परिवेश (इन-मेमोरी स्टोरेज, अलग-थलग रनर) से हैं। असली डिवाइस और असली स्टोर अलग-अलग होते हैं; ठीक इसीलिए स्टोर हेल्थ → प्रदर्शन अनुमानों के बजाय पिछले 24 घंटों में आपके काउंटर की मापी गई अनुरोध संख्या और सामान्य प्रतिक्रिया समय दिखाता है। उसका डेटा-मात्रा आँकड़ा एक न्यूनतम सीमा है, क्योंकि जिन प्रतिक्रियाओं में आकार घोषित नहीं होता वे शून्य जोड़ती हैं।
सर्वर-पक्ष ट्यूनिंग के लिए — होस्टिंग आवश्यकताएँ, HPOS, कैशिंग, और धीमी प्रतिक्रियाओं का निदान — देखें सर्वर प्रदर्शन।