चाहे आपने हाल ही में कोई ऐप्लिकेशन लॉन्च किया हो या पहले से ही ज़्यादा ट्रैफ़िक वाली कोई सेवा चला रहे हों, आपको इस गाइड में दी गई अहम जानकारी और सुझावों से फ़ायदा मिलेगा. इनसे आपको 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 पर ले जाने से ट्रैफ़िक में बढ़ोतरी हो सकती है.
कोटा टोकन के इस्तेमाल को पहले से लोड करना: कोटा विंडो के दौरान, अनुरोधों को बराबर-बराबर बांटने के बजाय, कोटा विंडो की शुरुआत में सभी कोटा टोकन खर्च करने पर, कोटा टोकन की संख्या में उतार-चढ़ाव होगा. इसे लोड-बैलेंस करना मुश्किल और महंगा होगा.
खास इवेंट: छुट्टियों (नए साल की शाम) या खेल-कूद के इवेंट (फीफा वर्ल्ड कप) के दौरान ट्रैफ़िक में बढ़ोतरी होती है.
"कर्व को फ़्लैट" करके, ट्रैफ़िक में होने वाली बढ़ोतरी को ठीक करना
इस सेक्शन में, ट्रैफ़िक में होने वाली बढ़ोतरी को कम करने के तरीकों के बारे में बताया गया है. इन तरीकों से, "बढ़ोतरी को कम किया जा सकता है."
FCM का इस्तेमाल सिर्फ़ सही इस्तेमाल के उदाहरणों के लिए करें
कुछ मामलों में, सूचना देने के लिए FCM का इस्तेमाल करना ज़रूरी या सही नहीं होता.
उदाहरण के लिए, कैलेंडर इवेंट की सूचनाओं के लिए, अपने ऐप्लिकेशन में कोई स्थानीय टास्क शेड्यूल किया जा सकता है. इससे, सूचना को ऐप्लिकेशन सर्वर से भेजने के बजाय, सही समय पर दिखाया जा सकता है. FCM मैसेज को कैलेंडर सिंक तक सीमित करें.
स्पाइक से बचना
स्केलिंग के लिए एक गलत तरीका यह है कि सर्वर साइड थ्रॉटलिंग लागू करने के बजाय, सिस्टम के अनुमति देने पर FCM सूचनाएं जल्द से जल्द भेजी जाएं. इन बातों का ध्यान रखें:
- क्या आपके सभी ग्राहकों को एक ही सूचना एक मिनट के अंदर मिलनी चाहिए? उदाहरण के लिए, क्या पांच मिनट की डिलीवरी विंडो, अब भी आपके कारोबार की ज़रूरतों को पूरा करेगी?
- क्या आपके ग्राहकों को प्राथमिकता के आधार पर सेगमेंट में बांटा जा सकता है, ताकि ट्रैफ़िक में होने वाली बढ़ोतरी को आसानी से मैनेज किया जा सके?
- क्या सूचनाओं को पहले से शेड्यूल किया जा सकता है?
जहां भी हो सके: ऐसी रणनीतियों से बचें जिनकी वजह से FCM को भेजे जाने वाले कोटा तुरंत खत्म हो जाए. ऐसा करने पर, टोकन बकेट फिर से भरते ही पैटर्न दोहराया जाएगा. ऐक्सेस के इस पैटर्न की वजह से, FCM और उससे जुड़े सिस्टम के लिए लोड-बैलेंसिंग की समस्याएं आती हैं. ट्रैफ़िक को धीरे-धीरे बढ़ाएं. कम से कम, 60 सेकंड की समय-सीमा में 0 से लेकर ज़्यादा से ज़्यादा आरपीएस तक रैंप करें. ज़्यादा आरपीएस के लिए, लंबी विंडो का इस्तेमाल करें.
"ऑन-द-आवर" ट्रैफ़िक से बचना
अगर हो सके, तो :00, :15, :30, और :45 मिनट के हर मार्क के दो मिनट के अंदर मैसेज भेजने से बचें.
सर्वर साइड ट्रॉथलिंग लागू करना
FCM पर आने वाले ट्रैफ़िक को मॉनिटर और मैनेज करने के लिए, सर्वर-साइड थ्रॉटलिंग लागू करें.
फिर से कोशिश करने की सुविधा को मैनेज करना
FCM, ज़्यादा से ज़्यादा उपलब्ध रहने की कोशिश करता है. हालांकि, कभी-कभी कुछ अनुरोधों का समय खत्म हो जाएगा या वे पूरा नहीं हो पाएंगे. इसकी कई वजहें हो सकती हैं. हालांकि, यहां दिए गए सबसे सही तरीके, मैसेज को जल्द से जल्द डिलीवर करने के लिए, फिर से कोशिश करने के व्यवहार को ऑप्टिमाइज़ करते हैं. इससे ट्रैफ़िक जाम होने का असर कम होता है.
टाइम आउट
फिर से कोशिश करने से पहले, अनुरोध भेजने के लिए कम से कम 10 सेकंड का टाइम आउट सेट करें. FCM के ज़्यादातर इंटरनल रिमोट प्रोसीज़र कॉल, 10 सेकंड के टाइम आउट का इस्तेमाल करते हैं.
गड़बड़ियां
- 400, 401, 403, 404 गड़बड़ियों के लिए: रोकें और फिर से कोशिश न करें.
- 429 कोड वाली गड़बड़ियों के लिए: retry-after हेडर में सेट की गई अवधि तक इंतज़ार करने के बाद, फिर से कोशिश करें. अगर 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 आरपीएस तक की बढ़ोतरी |
रोलबैक का काल्पनिक प्लान:
- अगर 95-पर्सेंटाइल इंतज़ार का समय 500 मि॰से॰ से ज़्यादा हो जाता है या किसी भी चरण में एक घंटे से ज़्यादा समय तक गड़बड़ी का अनुपात 1% से ज़्यादा हो जाता है, तो डाइनैमिक कॉन्फ़िगरेशन का इस्तेमाल करके तुरंत पिछले चरण पर वापस जाएं.
- जब तक इंतज़ार का समय और गड़बड़ी का अनुपात सामान्य लेवल पर न आ जाए, तब तक पिछले चरणों पर वापस जाएं.
FCM से संपर्क करने का समय
अगर इनमें से कोई भी समस्या आ रही है, तो Firebase की सहायता टीम के ज़रिए FCM से संपर्क करें:
- डिफ़ॉल्ट कोटा अब आपके इस्तेमाल के उदाहरण के हिसाब से नहीं हैं
- आपने तीन महीने की विंडो में, दुनिया भर में 1,00,000 आरपीएस या किसी महाद्वीप में 30,000 आरपीएस के स्केल पर, ईमेल भेजने के पैटर्न में बदलाव किया है.