चाहे आपने हाल ही में कोई ऐप्लिकेशन लॉन्च किया हो या पहले से ही ज़्यादा ट्रैफ़िक वाली कोई सेवा चला रहे हों, तो आपको इस गाइड की अहम जानकारी और सुझावों से फ़ायदा मिलेगा. इनसे आपको FCM की मदद से, अपने ऐप्लिकेशन या सेवा को आसानी से बड़े पैमाने पर उपलब्ध कराने का तरीका पता चलेगा. इन कॉन्सेप्ट और तरीकों की मदद से, आपको ज़्यादा मैसेज भेजने पर होने वाले नुकसान से बचा जा सकता है.
मुख्य शब्द और कॉन्सेप्ट
मैसेज का अनुरोध: FCM मैसेज का अनुरोध. इसे "अनुरोध", "मैसेज" या "क्वेरी" के साथ एक-दूसरे के बदले इस्तेमाल किया जाता है.
हर सेकंड आने वाले अनुरोध (आरपीएस): यह मेट्रिक, FCM को आने वाले अनुरोधों की दर के बारे में बताती है. इसका इस्तेमाल, हर सेकंड आने वाली क्वेरी (क्यूपीएस) के साथ किया जाता है.
कोटा टोकन, टोकन बकेट, और रीफ़िल: एफ़सीएम एचटीटीपी v1 एपीआई के ज़रिए मैसेज भेजते समय, हर अनुरोध के लिए तय समयसीमा में, तय किया गया कोटा टोकन खर्च होता है. इस विंडो को "टोकन बकेट" कहा जाता है. समयसीमा खत्म होने पर, यह फिर से भर जाती है. उदाहरण के लिए: एचटीटीपी v1 एपीआई, हर एक मिनट की टोकन बकेट के लिए 6 लाख कोटा टोकन देता है. यह हर एक मिनट की विंडो के आखिर में फिर से भर जाता है.
सर्वर-साइड थ्रॉटलिंग: जब ट्रैफ़िक की संख्या, FCM सेवा की क्षमता से ज़्यादा हो जाती है, तो भेजे जाने की क्षमता से ज़्यादा अनुरोधों को अस्वीकार कर दिया जाता है, ताकि इनग्रेस फ़्लो की दर को सीमित किया जा सके. 429 हेडर के साथ गड़बड़ी के retry-after जवाब दिए जा सकते हैं. इससे यह पता चलता है कि अनुरोध फिर से करने से पहले, आपको तय समय तक इंतज़ार करना चाहिए.
क्लाइंट-साइड थ्रॉटलिंग: जब क्लाइंट को अनुरोध पूरे नहीं होने, इंतज़ार का समय ज़्यादा या 429 गड़बड़ियां दिखती हैं, तो उन्हें अपनी मर्ज़ी से इग्रेस डेटा ट्रैफ़िक को सीमित करना चाहिए, ताकि ज़्यादा ट्रैफ़िक से बचा जा सके.
एक्सपोनेंशियल बैकऑफ़: गड़बड़ियों को दोबारा आज़माते समय, समय में बढ़ोतरी करें. उदाहरण के लिए: 1s, 2s, 4s, 8s, 16s, 32s.
जिटरिंग: तय समयावधि के हिसाब से अनुरोधों को दोबारा भेजने से बचना. जिटरिंग की मदद से, रिपीट करने में लगने वाले समय में बदलाव किया जाता है. ऐसा, रैंडम प्रोसेस की मदद से किया जाता है, ताकि समय के साथ उन्हें एक जैसा बांटा जा सके. उदाहरण के लिए: 0.9 सेकंड, 2.3 सेकंड, 4.1 सेकंड, 8.5 सेकंड, 17.9 सेकंड, 34.7 सेकंड.
फिर से कोशिश करने की संख्या बढ़ना: जब एक्सपोनेंशियल बैकऑफ़/जिटरिंग के बिना, पूरा न हो पाने वाले अनुरोधों को फिर से कोशिश की जाती है, तो वे अक्सर इकट्ठा हो जाते हैं और मौजूदा ट्रैफ़िक लोड में जुड़ जाते हैं. इससे ट्रैफ़िक जाम की समस्याएं "बढ़ती" हैं और गंभीर हो जाती हैं.
समस्या: ट्रैफ़िक में अचानक बढ़ोतरी
FCM हर सेकंड में लाखों अनुरोध (आरपीएस) प्रोसेस करता है. ट्रैफ़िक में अचानक बढ़ोतरी की वजह से, सिस्टम में रुकावटें आती हैं, इंतज़ार का समय बढ़ता है, और सेवाएं बंद हो जाती हैं.
स्पाइकी ट्रैफ़िक क्या है?
ट्रैफ़िक में बढ़ोतरी कई तरह की होती है.
हर घंटे के शुरुआती 30 सेकंड से दो मिनट के दौरान, FCM को दोगुना से ज़्यादा ट्रैफ़िक मिलता है. हालांकि, आधे घंटे और चौथाई घंटे के मार्क पर भी, कम संख्या में मिलते-जुलते स्पाइक दिखते हैं. उदाहरण के लिए: 00:15, 00:30, 00:45
फिर से बढ़ाने की कोशिश करें: एक्सपोनेन्शियल बैकऑफ़ के बिना, फ़ेल होने वाले या समय खत्म होने वाले अनुरोधों के लिए फिर से कोशिश करने से, मौजूदा ट्रैफ़िक क्रेस्ट के ऊपर ट्रैफ़िक की बार-बार होने वाली लहरें बढ़ सकती हैं.
ट्रैफ़िक पैटर्न में अचानक बदलाव: नए ट्रैफ़िक को FCM पर भेजने या धीरे-धीरे बढ़ाने जैसे फ़ैक्टर के बिना, सभी इलाकों में ट्रैफ़िक को FCM पर ले जाने से ट्रैफ़िक में बढ़ोतरी हो सकती है.
कोटा टोकन के इस्तेमाल को शुरुआत में लोड करना: कोटा विंडो के दौरान अनुरोधों को बराबर-बराबर बांटने के बजाय, कोटा विंडो की शुरुआत में सभी कोटा टोकन का इस्तेमाल करने से, कोटा टोकन की उपलब्धता में उतार-चढ़ाव होगा. इसे लोड-बैलेंस करना मुश्किल और महंगा होगा.
खास इवेंट: छुट्टियों (नए साल से पहले की शाम) या खेल-कूद के इवेंट (FIFA वर्ल्ड कप) के दौरान ट्रैफ़िक में बढ़ोतरी.
"कर्व को फ़्लैट करके" राहत देने वाले ट्रैफ़िक में बढ़ोतरी
इस सेक्शन में, ट्रैफ़िक में होने वाली बढ़ोतरी को कम करने के तरीकों के बारे में बताया गया है. इन तरीकों से, "बढ़ोतरी को कम किया जा सकता है."
FCM का इस्तेमाल सिर्फ़ सही इस्तेमाल के उदाहरणों के लिए करें
कुछ मामलों में, सूचना देने के लिए FCM का इस्तेमाल करना ज़रूरी या सही नहीं होता.
उदाहरण के लिए, कैलेंडर इवेंट की सूचनाओं के लिए, अपने ऐप्लिकेशन में कोई स्थानीय टास्क शेड्यूल किया जा सकता है. इससे, सूचना को ऐप्लिकेशन सर्वर से भेजने के बजाय, सही समय पर दिखाया जा सकता है. FCM मैसेज को कैलेंडर सिंक तक सीमित रखें.
स्पाइक से बचना
स्केलिंग के लिए एक गलत तरीका यह है कि सिस्टम जितना अनुमति देगा, FCM सूचनाएं उतनी ही तेज़ी से भेजी जाएं. इसके बजाय, सर्वर साइड थ्रॉटलिंग लागू करें. इन बातों का ध्यान रखें:
- क्या आपके सभी ग्राहकों को एक मिनट की विंडो में एक ही सूचना मिलना ज़रूरी है? उदाहरण के लिए, क्या पांच मिनट की डिलीवरी विंडो, अब भी आपके कारोबार की ज़रूरतों को पूरा करेगी?
- क्या आपके ग्राहकों को प्राथमिकता के आधार पर सेगमेंट में बांटा जा सकता है, ताकि ट्रैफ़िक में होने वाली बढ़ोतरी को आसानी से मैनेज किया जा सके?
- क्या सूचनाओं को पहले से शेड्यूल किया जा सकता है?
जहां भी हो सके: ऐसी रणनीतियों से बचें जिनकी वजह से FCM को भेजे जाने वाले कोटा तुरंत खत्म हो जाए. ऐसा करने पर, टोकन बकेट फिर से भरते ही पैटर्न दोहराया जाएगा. ऐक्सेस के इस पैटर्न की वजह से, FCM और उससे जुड़े सिस्टम के लिए लोड-बैलेंसिंग की समस्याएं आती हैं. ट्रैफ़िक को धीरे-धीरे बढ़ाएं. कम से कम, 60 सेकंड की समय-सीमा में 0 से लेकर ज़्यादा से ज़्यादा आरपीएस तक रैंप करें. ज़्यादा आरपीएस के लिए, लंबी विंडो का इस्तेमाल करें.
"ऑन-द-आवर" ट्रैफ़िक से बचना
अगर हो सके, तो :00, :15, :30, और :45 मिनट के हर मार्क के दो मिनट के अंदर मैसेज भेजने से बचें.
सर्वर साइड थ्रॉटलिंग लागू करें
FCM पर आने वाले ट्रैफ़िक को मॉनिटर और मैनेज करने के लिए, सर्वर-साइड थ्रॉटलिंग लागू करें.
फिर से कोशिश करने की सुविधा को मैनेज करना
FCM, ज़्यादा से ज़्यादा उपलब्ध रहने की कोशिश करता है. हालांकि, कभी-कभी कुछ अनुरोधों का समय खत्म हो जाएगा या वे पूरा नहीं हो पाएंगे. इसकी कई वजहें हो सकती हैं. हालांकि, यहां दिए गए सबसे सही तरीके, मैसेज को जल्द से जल्द डिलीवर करने के लिए, फिर से कोशिश करने की सुविधा को ऑप्टिमाइज़ करते हैं. इससे ट्रैफ़िक जाम होने पर होने वाले असर को कम किया जा सकता है.
टाइम आउट
फिर से कोशिश करने से पहले, अनुरोध भेजने के लिए कम से कम 10 सेकंड का टाइम आउट सेट करें. FCM के ज़्यादातर इंटरनल रिमोट प्रोसीज़र कॉल, 10 सेकंड के टाइम आउट का इस्तेमाल करते हैं.
गड़बड़ियां
- 400, 401, 403, 404 वाली गड़बड़ियों के लिए: रद्द करें और फिर से कोशिश न करें.
- 429 कोड वाली गड़बड़ियों के लिए: retry-after हेडर में सेट की गई अवधि तक इंतज़ार करने के बाद, फिर से कोशिश करें. अगर 'फिर से कोशिश करें' हेडर सेट नहीं है, तो डिफ़ॉल्ट रूप से 60 सेकंड पर सेट होता है.
- 500 कोड वाली गड़बड़ियों के लिए: एक्सपोनेंशियल बैकऑफ़ के साथ फिर से कोशिश करें.
एक्स्पोनेंशियल बैकऑफ़
अनुरोध दोबारा भेजने की संख्या बढ़ने से रोकने के लिए, अनुरोध दोबारा भेजने के लिए एक्सपोनेंशियल बैक-ऑफ़ लागू करें. उदाहरण के लिए, Firebase Admin SDK टूल, एक्सपोनेंशियल बैकऑफ़ लागू करता है.
यहां कुछ और सुझाई गई सेटिंग दी गई हैं:
- कम से कम इंटरवल: FCM के ज़रिए, पूरा न हो पाने वाले अनुरोध को तुरंत दोबारा न भेजें. पूरा न हो पाने वाले अनुरोध को फिर से करने से पहले, कम से कम 10 सेकंड इंतज़ार करें.
- ज़्यादा से ज़्यादा इंटरवल: अनुरोधों को बार-बार भेजने के बजाय, उन्हें छोड़ने के लिए ज़्यादा से ज़्यादा इंटरवल सेट करें.
अगर किसी अनुरोध को एक्सपोनेंशियल बैकऑफ़ के साथ बार-बार भेजा जाता है और 60 मिनट बाद भी वह पूरा नहीं होता है, तो हो सकता है कि उसे गलत तरीके से, फिर से कोशिश की जा सकने वाली गड़बड़ी के तौर पर कैटगरी में रखा गया हो. इसके अलावा, यह भी हो सकता है कि FCM में कोई रुकावट आ रही हो और बार-बार कोशिश करने से समस्या और भी बढ़ रही हो.
रोल आउट और रोलबैक प्लान बनाना और धीरे-धीरे बदलाव करना
ट्रैफ़िक में बड़े पैमाने पर बदलाव करने, जैसे कि FCM पर ट्रैफ़िक बढ़ाना या ट्रैफ़िक को पूरे क्षेत्रों या नेटवर्क में शिफ़्ट करना, रोल आउट/रोलबैक प्लान डिज़ाइन करना, और धीरे-धीरे बदलाव लागू करना आपके उपयोगकर्ताओं, आपकी सेवा, और FCM को सुरक्षित रखता है.
- रोल आउट प्लान, हिस्सेदारों के लिए उम्मीदों को पूरा करता है. कुछ स्थितियों में (जिनके बारे में नीचे बताया गया है), हो सकता है कि आप FCM टीम के साथ रोल आउट का प्लान पहले से शेयर करना चाहें, ताकि आपको कोई परेशानी न हो.
- रोलबैक प्लान की मदद से, आपातकालीन स्थितियों के लिए तैयारी की जा सकती है. साथ ही, अचानक होने वाली गड़बड़ियों से तुरंत और सुरक्षित तरीके से उबरने के लिए, तरीके तैयार किए जा सकते हैं.
- धीरे-धीरे बदलाव करने के दो पहलू हैं:
- "सिलसिलेवार" रैंप-अप: रैंप-अप के चरण 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% या उससे बेहतर होने चाहिए. एक दिन से एक हफ़्ते के लिए, हर चरण को "सोचें" (लोड होने के दौरान सिस्टम के काम करने के तरीके पर नज़र रखें). इससे, आपको अगले "अपग्रेड" से पहले संभावित समस्याओं का पता चलता है
- ट्रैफ़िक को धीरे-धीरे बढ़ाना: ट्रैफ़िक बढ़ाने के लिए हर "कदम" उठाते समय, कम से कम एक घंटे के लिए ट्रैफ़िक को आसान बनाएं. इससे FCM के लोड-बैलेंसिंग इंफ़्रास्ट्रक्चर को आपके नए ट्रैफ़िक को सही तरीके से बढ़ाने में मदद मिलती है. साथ ही, हॉटस्पॉट और ट्रैफ़िक जाम होने की संभावना को कम किया जा सकता है.
यहां दुनिया भर में 5,00,000 आरपीएस को FCM के लेगसी एचटीटीपी एपीआई से FCM एचटीटीपी v1 एपीआई में माइग्रेट करने के बारे में एक अनुमान दिया गया है:
| हफ़्ता | चरण | धीरे-धीरे रैंप-अप करने की रणनीति |
|---|---|---|
| 0 | 1% रैंप-अप | एक घंटे में, FCM एचटीटीपी v1 पर 0 से 5,000 आरपीएस तक आसानी से बढ़ाएं. |
| 1 | 5% रैंप-अप | दो घंटे में, 5,000 से 25,000 आरपीएस तक आसानी से बढ़ाया जा सकता है. |
| 2 | 10% रैंप-अप | दो घंटे में 25,000 से 50,000 आरपीएस तक आसानी से बढ़ाना |
| 3 | 25% रैंप-अप | तीन घंटे में 50,000 से 1,25,000 आरपीएस तक बढ़ाना |
| 4 | 50% रैंप-अप | छह घंटे में 1,25,000 से 2,50,000 आरपीएस तक की बढ़ोतरी |
| 5 | 75% रैंप-अप | छह घंटे में 2,50,000 से 3,75,000 आरपीएस तक की बढ़ोतरी |
| 6 | 100% रैंप-अप | छह घंटे में 3,75,000 से 5,00,000 आरपीएस तक की बढ़ोतरी |
रोलबैक का काल्पनिक प्लान:
- अगर किसी चरण में एक घंटे से ज़्यादा समय तक गड़बड़ी का अनुपात 1% से ज़्यादा हो जाता है या गड़बड़ी का अनुपात 1% से ज़्यादा हो जाता है, तो पिछले चरण पर तुरंत रोल बैक करने के लिए, डाइनैमिक कॉन्फ़िगरेशन का इस्तेमाल करें. ऐसा तब करें, जब 95-प्रतिशत के इंतज़ार का समय 500 मि॰से॰ से ज़्यादा हो जाए.
- जब तक इंतज़ार का समय और गड़बड़ी का अनुपात सामान्य लेवल पर न आ जाए, तब तक पिछले चरणों पर वापस जाएं.
FCM से संपर्क करने का समय
अगर इनमें से कोई भी समस्या आ रही है, तो Firebase की सहायता टीम के ज़रिए FCM से संपर्क करें:
- डिफ़ॉल्ट कोटा अब आपके इस्तेमाल के उदाहरण के हिसाब से नहीं हैं
- आपने तीन महीने की विंडो में, ईमेल भेजने के पैटर्न में बदलाव किया है. इस दौरान, दुनिया भर में 1,00,000 RPS या कॉन्टिनेंटल तरीके से 30,000 RPS के हिसाब से क्रम में बदलाव किया जा रहा है.