हमने Moove की परफ़ॉर्मेंस 59% कैसे बेहतर की

दूरी हमारी सबसे धीमी डिपेंडेंसी थी

Moove app खोलने वाले ज़्यादातर लोग नाइजीरिया और इंडोनेशिया के मोबाइल नेटवर्क पर होते हैं, उन सर्वरों से हज़ारों किलोमीटर दूर जो उन्हें जवाब देते हैं। इस महीने हमने बदला कि उनके अनुरोध हम तक कैसे पहुँचते हैं, और हमारा पहले बाइट तक का समय (TTFB), यानी फ़ोन के अनुरोध भेजने और जवाब का पहला हिस्सा पहुँचने के बीच का समय, 59% घट गया: 0.74 सेकंड से 0.31 सेकंड। इसके लिए हमने एक भी सर्वर नहीं हिलाया।

यह पोस्ट बताती है कि दूरी ने हमें उम्मीद से ज़्यादा क्यों महँगा पड़ा, हमने क्या बदला, वह हिस्सा जो खुद बदलाव से ज़्यादा मुश्किल निकला, और यही काम करने जा रही किसी दूसरी टीम से हम क्या कहेंगे।

एक लंबा सफ़र तीन कैसे बन जाता है

इंजीनियर कुछ भेजने और उसके पहुँचने के बीच की देरी को विलंबता (latency) कहते हैं, और किसी संदेश के सर्वर तक पहुँचने और जवाब के लौटने में लगे समय को राउंड-ट्रिप टाइम (RTT)। लागोस से हमारे सर्वरों तक RTT 200 से 300 मिलीसेकंड के बीच है। अकेले यह बर्दाश्त करने लायक है। समस्या यह है कि अनुरोध शायद ही कभी अकेला सफ़र करता है।

सुरक्षित कनेक्शन पर कुछ भी माँगने से पहले फ़ोन को दो हैंडशेक (handshake) पूरे करने पड़ते हैं, यानी कनेक्शन बनाने वाली छोटी बातचीत। TCP हैंडशेक कनेक्शन खोलता है, और फिर TLS हैंडशेक वे एन्क्रिप्शन की (keys) तय करता है जो उसे निजी रखती हैं। हर एक में पूरा एक राउंड ट्रिप लगता है। उसके बाद ही असल अनुरोध जाता है, जो तीसरा सफ़र है। 250 मिलीसेकंड प्रति सफ़र के हिसाब से, हमारे सर्वर कोई काम शुरू करें, उससे पहले ही यूज़र को लगभग पौन सेकंड इंतज़ार करना पड़ता है।

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

हम लागोस को अपने सर्वरों के पास नहीं ला सकते थे। हम सेटअप को लागोस के पास ला सकते थे।

सर्वर नहीं, हैंडशेक को पास लाना

कंटेंट डिलीवरी नेटवर्क (CDN) को आम तौर पर कैश के रूप में बताया जाता है: दुनिया भर की जगहों का एक समूह जो फ़ाइलों की प्रतियाँ रखता है ताकि वे पास से परोसी जा सकें। हमने इसे अलग वजह से इस्तेमाल किया। हमारे API के लिए, यानी वह इंटरफ़ेस जिससे ऐप अपने हर काम के लिए बात करता है, कैशिंग पूरी तरह बंद है। हर अनुरोध अब भी हमारे ऑरिजिन (origin) तक जाता है, जो इसके पीछे के सर्वरों के लिए CDN का नाम है।

बदलाव यह है कि कनेक्शन कहाँ से शुरू होता है। फ़ोन अब अपना कनेक्शन सबसे नज़दीकी एज लोकेशन (edge location) से खोलता है, जिसे पॉइंट ऑफ़ प्रेज़ेंस (PoP) भी कहते हैं: CDN की दुनिया भर में फैली जगहों में से एक, जो अक्सर सैकड़ों नहीं बल्कि कुछ दहाई मिलीसेकंड दूर होती है। एज TLS टर्मिनेशन (TLS termination) करता है, यानी फ़ोन से आने वाला सुरक्षित कनेक्शन वहीं खत्म हो जाता है। फिर वह हमारे ऑरिजिन तक वार्म कनेक्शनों का एक पूल दोबारा इस्तेमाल करता है, जिसे keep-alive से खुला रखा जाता है, एक ऐसी सेटिंग जो अनुरोधों के बीच कनेक्शन को बंद करने की जगह खुला छोड़ देती है। दो महँगे सेटअप सफ़र छोटी दूरी पर होते हैं, और सिर्फ़ अनुरोध खुद महासागर पार करता है, एक ऐसे कनेक्शन पर जो पहले से वार्म है।

तीन लंबे सफ़र एक लंबे और दो छोटे सफ़र बन जाते हैं। पूरा विचार बस इतना है।

बाकी सब हमने जानबूझकर साधारण रखा:

• क्लाइंट को कुछ पता नहीं चला। ऐप और वेबसाइट के पते वही रहे, इसलिए किसी ऐप रिलीज़ की ज़रूरत नहीं पड़ी और किसी को कुछ अपडेट नहीं करना पड़ा।
• विफलता का व्यवहार वही रहा। टाइमआउट पहले जैसे ही हैं, इसलिए जो पहले फेल होता था वह अब भी उसी तरह फेल होता है। हम कोई नए तरह की एरर नहीं चाहते थे।
• एज निष्क्रिय कनेक्शन पहले बंद करता है। हर कनेक्शन का एक आइडल टाइमआउट (idle timeout) होता है, यानी बिना इस्तेमाल के वह कितनी देर पड़ा रह सकता है, उसके बाद वह बंद हो जाता है। अगर हमारे सर्वर किसी शांत कनेक्शन को बंद कर दें जबकि एज उसे अब भी खुला समझे, तो अगला अनुरोध फेल हो जाएगा। एज का टाइमआउट छोटा रखने से वह हमेशा पहले हार मानता है और नया कनेक्शन खोल लेता है।
• फ़ोन के लिए नए प्रोटोकॉल। फ़ोन HTTP/3 पर कनेक्ट हो सकते हैं, जो वेब के अनुरोध प्रोटोकॉल का सबसे नया संस्करण है। यह QUIC पर चलता है, जो दोनों हैंडशेक को एक ही राउंड ट्रिप में समेट देता है और मोबाइल नेटवर्क पर आम पैकेट लॉस को बेहतर संभालता है।
• कोई क्षेत्र छूटा नहीं। एज नेटवर्क के सस्ते टियर अक्सर दुनिया के ठीक उन्हीं हिस्सों की लोकेशन छोड़ देते हैं जहाँ हमारे यूज़र्स रहते हैं, इसलिए हमने पूरी कवरेज चुनी।

हमने क्या मापा

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

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

ये आँकड़े एक शहर से हैं, कोई वैश्विक बेंचमार्क नहीं। फिर भी यह गणित लागोस और जकार्ता पर भी लागू होता है, और हमारे यूज़र्स वहीं हैं।

असली मुश्किल यह जानना था कि कॉल कौन कर रहा है

अपने सर्वरों के आगे कुछ रख देना आसान है। उसके पीछे अपनी सुरक्षा को काम करता रखना ही वह जगह है जहाँ ज़्यादातर मेहनत लगी।

ज़्यादातर पेमेंट प्लेटफ़ॉर्म की तरह Moove रेट लिमिटिंग (rate limiting) इस्तेमाल करता है, यानी किसी एक कॉलर को तय समय में कितने अनुरोध करने दिए जाएँ इस पर सीमा, और ये सीमाएँ कॉलर के IP एड्रेस (IP address) पर टिकी होती हैं, वह नंबर जो इंटरनेट पर किसी डिवाइस की पहचान कराता है। एज नेटवर्क के पीछे हर अनुरोध यूज़र के पते की जगह किसी एज लोकेशन के पते से आता है। अगर और कुछ न बदला जाता, तो लागोस के सभी लोग एक ही बजट साझा करते, और एक व्यस्त दोपहर उन लोगों को लौटाना शुरू कर देती जिन्होंने कुछ गलत नहीं किया था।

समाधान दो विचारों पर टिका है।

ठीक उतनी ही परतों पर भरोसा करें जितनी आपके पास हैं। CDN एक तरह का रिवर्स प्रॉक्सी (reverse proxy) है, यानी आपके सर्वर के आगे बैठा एक सर्वर जो अनुरोधों को आगे भेजता है। हर प्रॉक्सी उस पते को, जहाँ से उसे अनुरोध मिला, X-Forwarded-For नाम के एक मानक हेडर में जोड़ देता है, इसलिए असली कॉलर उस सूची में पीछे की ओर एक तय संख्या के कदम, यानी हॉप (hop), दूर होता है। यह संख्या गलत हो तो दोनों दिशाओं में बग है। बहुत कम परतें गिनें तो हर यूज़र अपनी एज लोकेशन जैसा दिखता है। बहुत ज़्यादा गिनें तो आप ऐसी एंट्री पर भरोसा करने लगते हैं जो कॉलर ने खुद लिखी थी। इसलिए हमने इस संख्या को कोड की नहीं, इंफ्रास्ट्रक्चर की प्रॉपर्टी बना दिया। यह ठीक उसी पल बदलती है जब नेटवर्क बदलता है, और अगर मान का कोई मतलब न निकले तो हमारी सर्विस अंदाज़ा लगाने की जगह शुरू होने से इनकार कर देती है।

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

एक बग जो शिप होने से पहले पकड़ा गया

Moove Profiles किसी मर्चेंट के अपने डोमेन पर चल सकते हैं। उन डोमेन के अनुरोध हमारी वेबसाइट से होकर मर्चेंट के डोमेन के साथ गुज़रते थे, ताकि साइट को पता रहे कि कौन-सा प्रोफ़ाइल दिखाना है।

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

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

सामान्य सबक: जब आप ऐसी परत जोड़ें जो इनपुट साफ़ करती है, तो उस हर चीज़ को खोजें जो उन इनपुट पर निर्भर थी जिन्हें आप साफ़ करने वाले हैं।

हमने इसे कैसे रोलआउट किया

पेमेंट इंफ्रास्ट्रक्चर में "डिप्लॉय करो और देखो" नहीं चलता, इसलिए हमने पहले स्टेजिंग बदली और प्रोडक्शन बाद में, और कुछ फ़ैसलों ने कटओवर को सहज रखा। हमने अपने DNS रिकॉर्ड का TTL (time to live) घटाया, DNS इंटरनेट की वह डायरेक्टरी है जो moove.xyz जैसे नाम को सर्वर के पते में बदलती है। TTL बताता है कि बाकी इंटरनेट उस जवाब को कितनी देर कैश कर सकता है, और हमने उसे एक घंटे से घटाकर पाँच मिनट किया, कुछ भी हिलने से पूरे एक घंटा पहले, ताकि पुराना जवाब हर जगह खत्म हो चुका हो और रोलबैक कुछ ही मिनटों में असर करे। हमने एड्रेस रिकॉर्ड ऐसे रूप में रखे जिन्हें उसी जगह बदला जा सके, क्योंकि उन्हें हटाकर दोबारा बनाने से एक खाली अंतराल रह जाता, और खाली अंतराल का मतलब आउटेज है। हर जोखिम भरा कदम अपना एक छोटा बदलाव था, जिसे पलटने के कदम क्रम से लिखे हुए थे।

किसी दूसरी टीम से हम क्या कहेंगे

अगर आपके यूज़र्स आपके सर्वरों से दूर हैं, तो एज नेटवर्क तब भी रखने लायक है जब वह कुछ कैश न करे। कटओवर से पहले:

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

आगे की राह

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

पैसे को नेटवर्क की रफ़्तार से चलना चाहिए, महासागर पार करती रोशनी की रफ़्तार से नहीं।

अगर आप Moove के ऊपर बनाते हैं, तो Web3 पेमेंट API और SDK का हमारा परिचय और Moove Developer Program पढ़िए।

moove.xyz इंजीनियरिंग टीम द्वारा लिखा गया।

moove.xyz के बारे में

moove.xyz एक ग्लोबल Web3 फिनटेक प्लेटफ़ॉर्म है, जो पैसे और वैल्यू को permissionless और आसान तरीके से भेजने के लिए बना है। हम दुनिया में कहीं भी बिज़नेस और आम यूज़र्स को एक ही प्लेटफ़ॉर्म पर किसी भी ब्लॉकचेन पर कोई भी क्रिप्टोकरेंसी भेजने, पाने, staking करने और स्वैप करने की ताकत देते हैं।

हम दुनिया की उन पहली Web3 फिनटेक कंपनियों में हैं जिन्होंने फ़ुल-स्टैक क्रिप्टो पेमेंट और decentralised finance इंफ्रास्ट्रक्चर बनाया है। इससे मल्टी-चेन वॉलेट एक्सेस, पर्सनलाइज़्ड वॉलेट हैंडल, cross-chain टोकन स्वैप, एम्बेडेड cross-chain ट्रांज़ैक्शन और एक decentralised सोशल फ़ाइनेंशियल नेटवर्क, सब एक साथ और व्यापक रूप से मिलते हैं। हमारे मुख्य प्रोडक्ट में Moove Profile, Moove Send, Moove Receive, Moove Stake, Moove Swap, Moove Rewards, Moove Discover और बहुत कुछ शामिल हैं।

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

आपका पैसा। आपका फ़ैसला।