बड़े पैमाने पर FCM मैसेज भेजने के सबसे सही तरीके

चाहे आप कोई नया ऐप्लिकेशन डेवलप कर रहे हों या पहले से ही ज़्यादा ट्रैफ़िक वाली सेवा चला रहे हों, आपको FCM की मदद से आसानी से अपनी पहुंच बढ़ाने के बारे में इस गाइड की अहम जानकारी और सुझाव मिल सकते हैं. इन सिद्धांतों और तरीकों की मदद से, बड़ी संख्या में मैसेज भेजने की ज़रूरत पड़ने पर गलत असर से बचा जा सकता है.

मुख्य शब्द और सिद्धांत

मैसेज का अनुरोध: FCM मैसेज का अनुरोध; "अनुरोध", "मैसेज" या "क्वेरी" के साथ एक-दूसरे की जगह इस्तेमाल किया जाता है.

हर सेकंड के अनुरोध (आरपीएस): इस मेट्रिक से, FCM को मिलने वाले अनुरोधों की दर के बारे में पता चलता है. इसे क्वेरी-प्रति-सेकंड (क्यूपीएस) के साथ बदला जाता है.

कोटा टोकन, टोकन बकेट, और रीफ़िल: FCM एचटीटीपी v1 एपीआई के लिए मैसेज भेजते समय, हर अनुरोध एक टाइम विंडो में असाइन किए गए कोटा टोकन का इस्तेमाल करता है. इस विंडो को "टोकन बकेट" कहते हैं. इसमें समय खत्म होने पर, इसमें रीफ़िल हो जाती है. उदाहरण के लिए: एचटीटीपी v1 API, हर एक मिनट के टोकन बकेट के लिए 6 लाख कोटा टोकन देता है. टोकन बकेट हर एक मिनट की विंडो के आखिर में फिर से भर जाता है.

सर्वर-साइड थ्रॉटलिंग: जब ट्रैफ़िक की संख्या FCM सेवा की क्षमता से ज़्यादा हो जाती है, तब सेवा देने की क्षमता से ज़्यादा अनुरोध अस्वीकार कर दिए जाते हैं, ताकि इन्ग्रेस डेटा ट्रैफ़िक को सीमित किया जा सके. ऐसा हो सकता है कि retry-after हेडर वाले 429 गड़बड़ी के जवाबों को दिखाया जाए. इससे यह पता चलता है कि आपको फिर से अनुरोध करने से पहले, किसी तय समयावधि तक इंतज़ार करना चाहिए.

क्लाइंट-साइड थ्रॉटलिंग: जब क्लाइंट को अनुरोध पूरा नहीं होने, इंतज़ार का समय ज़्यादा या 429 गड़बड़ियां दिखती हैं, तो उन्हें अपनी मर्ज़ी से इग्रेस डेटा ट्रैफ़िक को सीमित करना चाहिए, ताकि ज़्यादा ट्रैफ़िक से बचा जा सके.

एक्सपोनेन्शियल बैकऑफ़: गड़बड़ियों को फिर से करने की कोशिश करते समय, समय में तेज़ी से होने वाली देरी को जोड़ें. उदाहरण के लिए: 1s, 2s, 4s, 8s, 16s, 32s.

एक बार फिर से अनुरोध करने की कोशिश करना: सटीक इंटरवल पर फिर से अनुरोध करने की कोशिश न करना. सिग्नल में गड़बड़ी होने पर, फिर से कोशिश करने में होने वाली देरी में बदलाव हो सकता है. ऐसा किसी भी रैंडम प्रोसेस के ज़रिए किया जा सकता है, ताकि समय के साथ-साथ डेटा को समान रूप से डिस्ट्रिब्यूट किया जा सके. उदाहरण के लिए: 0.9, 2.3, 4.1, 8.5, 17.9, 34.7 सेकंड.

फिर से बढ़ाने की कोशिश: जब तेज़ी से होने वाले अनुरोधों के असर को तेज़ी से बढ़ाने की कोशिश के बिना ही फिर से कोशिश की जाती है, तो अक्सर ये अनुरोध इकट्ठा हो जाते हैं और ट्रैफ़िक की स्थिति बढ़ा देते हैं. इससे ट्रैफ़िक में “बढ़ोतरी” हो सकती है और ट्रैफ़िक जाम की समस्याएं बढ़ जाती हैं.

समस्या: ट्रैफ़िक में बढ़ोतरी

FCM लाखों अनुरोध प्रति सेकंड (RPS) प्रोसेस करता है. ट्रैफ़िक बढ़ने, इंतज़ार के समय से जुड़ी समस्याओं, और रुकावटों की सबसे बड़ी वजह ट्रैफ़िक में हुई बढ़ोतरी है.

ज़्यादा ट्रैफ़िक क्या होता है?

ट्रैफ़िक में कई तरह की बढ़ोतरी हो सकती है.

घंटे के हिसाब से बढ़ोतरी: FCM को शुरुआती 30 सेकंड से लेकर हर घंटे दो मिनट तक, दोगुना से ज़्यादा ट्रैफ़िक मिलता है. इसी तरह, हालांकि, कम, बढ़ोतरी को भी आधे घंटे और तिमाही घंटे के चिह्नों पर देखा जाता है (उदाहरण: 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 गड़बड़ियों के लिए: 'फिर से कोशिश करें' हेडर में सेट की गई अवधि तक इंतज़ार करने के बाद फिर से कोशिश करें. अगर 'फिर से कोशिश करें' हेडर सेट नहीं है, तो डिफ़ॉल्ट रूप से 60 सेकंड पर सेट होता है.
• 500 गड़बड़ियों के लिए: एक्स्पोनेंशियल बैकऑफ़ के साथ फिर से कोशिश करें.

एक्स्पोनेंशियल बैकऑफ़

फिर से कोशिश करने की क्षमता को बढ़ाने से बचने के लिए, फिर से कोशिश करने के अनुरोधों के लिए एक्सपोनेन्शियल बैक-ऑफ़ लागू करें. उदाहरण के लिए, Firebase एडमिन SDK टूल एक्स्पोनेंशियल बैकऑफ़ लागू करता है.

यहां सुझाई गई कुछ और सेटिंग दी गई हैं:

• कम से कम इंटरवल: FCM का इस्तेमाल न हो पाने पर, तुरंत दोबारा अनुरोध न करें. किसी असफल अनुरोध को फिर से करने से पहले, कम से कम 10 सेकंड इंतज़ार करें.
• ज़्यादा से ज़्यादा इंटरवल: अनिश्चित समय तक फिर से कोशिश करने के बजाय, उन अनुरोधों को ड्रॉप करने के लिए ज़्यादा से ज़्यादा इंटरवल सेट करें जो सही समय पर सही नहीं होते.

अगर किसी अनुरोध के लिए लगातार एक्सपोनेन्शियल बैकऑफ़ के साथ फिर से कोशिश की जाती है और 60 मिनट बाद भी विफल हो रहा है, तो उसे या तो फिर से कोशिश करने लायक गड़बड़ी के रूप में गलत कैटगरी में रखा जाता है या FCM की सुविधा कुछ समय के लिए उपलब्ध न होने की स्थिति में हो सकती है.

रोल आउट और रोल बैक के लिए प्लान बनाना. इसके बाद, धीरे-धीरे बदलाव करना

ट्रैफ़िक में बड़े पैमाने पर बदलाव करने, जैसे कि FCM पर ट्रैफ़िक बढ़ाना या ट्रैफ़िक को पूरे क्षेत्रों या नेटवर्क में शिफ़्ट करना, रोल आउट/रोलबैक प्लान डिज़ाइन करना, और धीरे-धीरे बदलाव लागू करना आपके उपयोगकर्ताओं, आपकी सेवा, और FCM को सुरक्षित रखता है.

• रोल आउट प्लान, हिस्सेदारों के लिए उम्मीदों को पूरा करता है. कुछ परिस्थितियों (नीचे बताई गई) में, आप सरप्राइज़ से बचने के लिए अपनी रोल आउट योजना को FCM टीम के साथ समय से पहले शेयर कर सकते हैं.
• रोलबैक प्लान की मदद से, अनचाहे बदलावों को ध्यान में रखा जा सकता है. साथ ही, ऐसी गड़बड़ियों को तुरंत और सुरक्षित तरीके से ठीक किया जा सकता है जिनकी उम्मीद न की जा रही हो.
• धीरे-धीरे बदलाव करने के दो पहलू हैं:
  • "अलग-अलग चरणों में" रैंप-अप: कदम 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% या इससे छोटे होने चाहिए. एक दिन से एक हफ़्ते के लिए, हर चरण को "सोचें" (लोड होने के दौरान सिस्टम के काम करने के तरीके पर नज़र रखें). इससे आपको अगले "चरण" से पहले संभावित समस्याओं का पता लगाने की सुविधा मिलती है
  • ट्रैफ़िक में धीरे-धीरे बढ़ोतरी होना: ट्रैफ़िक को बढ़ाने के लिए हर "चरण" का इस्तेमाल करते समय, कम से कम एक घंटे के दौरान ट्रैफ़िक को समान रूप से आगे बढ़ाया जा सकता है. इससे FCM का लोड बैलेंसिंग इन्फ़्रास्ट्रक्चर, आपके नए ट्रैफ़िक को सही तरीके से बढ़ा पाता है. साथ ही, हॉटस्पॉट और भीड़ की संभावना को कम कर पाता है.

यहां दुनिया भर में 5,00,000 आरपीएस को FCM के लेगसी एचटीटीपी एपीआई से FCM एचटीटीपी v1 एपीआई में माइग्रेट करने के बारे में एक अनुमान दिया गया है:

हफ़्ता	चरण	रैंप-अप की धीरे-धीरे बढ़ने की रणनीति
0	1% रैंप-अप	एक घंटे में 0 से 5,000 RPS से FCM HTTP v1 तक आसानी से रैंप-अप करें.
1	5% रैंप-अप	रैंप-अप की प्रोसेस को दो घंटों में 5,000 से 25,000 RPS तक आसानी से बढ़ाएं.
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 आरपीएस या कॉन्टिनेंटल तरीके से 30,000 आरपीएस का इस्तेमाल किया जा सकता है.