चाहे आपको नया ऐप्लिकेशन डेवलप करना हो या पहले से ही ज़्यादा ट्रैफ़िक वाली सेवा चालू करनी हो, इस गाइड की अहम जानकारी और सुझावों की मदद से, कारोबार को कैसे बढ़ाना है, FCM के साथ आसानी से काम किया जा सकता है. ये कॉन्सेप्ट और प्रैक्टिस, आपको बुरी चीज़ों से बचाने में मदद कर सकती हैं का असर तब पड़ता है, जब आपको ज़्यादा संख्या में मैसेज भेजने की ज़रूरत होती है.
मुख्य शब्द और सिद्धांत
मैसेज का अनुरोध: एक FCM मैसेज अनुरोध; "अनुरोध" के साथ एक-दूसरे की जगह पर इस्तेमाल किया जाता है, "मैसेज" या "क्वेरी".
अनुरोध-प्रति-सेकंड (RPS): इनकमिंग ट्रैफ़िक की दर की जानकारी देने वाली मेट्रिक FCM के अनुरोध; इसे क्वेरी-प्रति-सेकंड (क्यूपीएस) के साथ एक-दूसरे की जगह पर इस्तेमाल किया जाता है.
कोटा टोकन, टोकन बकेट, और रीफ़िल: FCM एचटीटीपी v1 एपीआई, हर अनुरोध के लिए एक तय समय में, तय किए गए कोटा टोकन का इस्तेमाल किया जाता है विंडो. इस विंडो को "टोकन बकेट" कहते हैं. इसके आखिर में रीफ़िल होती है समय विंडो. उदाहरण के लिए: एचटीटीपी v1 API, हर एक के लिए 6 लाख कोटा टोकन देता है एक मिनट का टोकन बकेट, जो हर एक मिनट की विंडो के आखिर में फिर से भर जाता है.
सर्वर-साइड थ्रॉटलिंग: जब ट्रैफ़िक की मात्रा FCM सेवा की
CANNOT TRANSLATE
फ़्लो. यह बताने के लिए कि retry-after हेडर के साथ गड़बड़ी के 429 रिस्पॉन्स दिखाए जा सकते हैं
यह कि अनुरोध को फिर से करने से पहले, आपको एक तय समयसीमा तक इंतज़ार करना होगा.
क्लाइंट-साइड थ्रॉटलिंग: जब क्लाइंट को अनुरोध पूरा नहीं होने, इंतज़ार का समय ज़्यादा,
या 429 गड़बड़ियां हो सकती हैं, तो उन्हें अपने-आप ही इग्रेस डेटा ट्रैफ़िक को सीमित कर देना चाहिए, ताकि यह समस्या और बढ़ न जाए
बहुत ज़्यादा व्यस्त रहता है.
एक्सपोनेन्शियल बैकऑफ़: फिर से कोशिश करते समय, देरी को तेज़ी से जोड़ें. उदाहरण के लिए: 1s, 2s, 4s, 8s, 16s, 32s.
एक बार फिर से अनुरोध करने की कोशिश करना: सटीक इंटरवल पर फिर से अनुरोध करने की कोशिश न करना. हिलते-डुलते, उन्हें समान रूप से डिस्ट्रिब्यूट करने के लिए, किसी भी प्रोसेस से दोबारा कोशिश करने में लगने वाले समय में बदलाव किया जा सकता है समय के साथ (उदाहरण के लिए: 0.9s, 2.3s, 4.1s, 8.5s, 17.9s, 34.7s).
फिर से बढ़ाने की कोशिश करें: जब अनुरोध पूरा नहीं किया जा सकता, तो एक्सपोनेन्शियल के बिना फिर से कोशिश की जाती है बैकऑफ़/झुकाने वाला होता है. ये अक्सर इकट्ठा होते हैं और लगातार जारी ट्रैफ़िक लोड के साथ बढ़ जाते हैं. संभावित तौर पर "बढ़ाया जा रहा है" और ट्रैफ़िक जाम की समस्याओं को बढ़ा देती हैं.
समस्या: ट्रैफ़िक में बढ़ोतरी
FCM लाखों अनुरोध प्रति सेकंड (RPS) प्रोसेस करता है. इसमें सबसे ज़्यादा योगदान देने वाला सिस्टम में ज़्यादा ट्रैफ़िक, इंतज़ार के समय की समस्याएं, और कुछ समय के लिए उपलब्ध न होने की वजह, ट्रैफ़िक में बढ़ोतरी है.
ज़्यादा ट्रैफ़िक क्या होता है?
ट्रैफ़िक में कई तरह की बढ़ोतरी हो सकती है.
हर घंटे बढ़ोतरी: पहले 30 घंटों के दौरान, FCM को दोगुने से भी ज़्यादा ट्रैफ़िक मिलता है सेकंड से लेकर दो मिनट तक. इसी तरह, कम बढ़ोतरी के साथ-साथ आधे घंटे और चौथाई घंटे के चिह्नों पर देखा गया (उदाहरण: 00:15, 00:30, 00:45)
फिर से बढ़ाने की कोशिश करें: बिना किसी गड़बड़ी के या तय समय में किए गए अनुरोधों के लिए फिर से कोशिश करें एक्सपोनेंशियल बैकऑफ़ ये काम कर सकते हैं मौजूदा ट्रैफ़िक क्रेस्ट के ऊपर ट्रैफ़िक की बार-बार होने वाली तरंगों में इकट्ठा हो जाता है.
ट्रैफ़िक पैटर्न में अचानक बदलाव: नए ट्रैफ़िक को FCM पर भेजना या ट्रैफ़िक ले जाना धीरे-धीरे रैंप-अप होने जैसी चीज़ों में सुधार के बिना, अलग-अलग क्षेत्रों में FCM के लिए की वजह से बढ़ोतरी होती है.
फ़्रंट-लोडिंग कोटा टोकन का इस्तेमाल: शुरुआत में सभी कोटा टोकन खत्म होते हैं अनुरोधों को पूरे कोटे में समान रूप से बांटने के बजाय कोटा विंडो विंडोज़ चालू होने पर हिलने-डुलने में दिक्कत होगी, जो मुश्किल और खर्ची होगी लोड-बैलेंस.
खास इवेंट: छुट्टियों (नए साल से पहले की शाम) या खेल-कूद के इवेंट के दौरान ट्रैफ़िक में बढ़ोतरी (FIFA विश्व कप).
"कर्व को फ़्लैट करके" राहत देने वाले ट्रैफ़िक में बढ़ोतरी
इस सेक्शन में बताया गया है कि ट्रैफ़िक में बढ़ोतरी को कम करने के लिए किन रणनीतियों का इस्तेमाल किया जा सकता है "कर्व को फ़्लैट करने की रणनीतियाँ बनाईं."
FCM का इस्तेमाल सिर्फ़ सही इस्तेमाल के उदाहरणों के लिए करें
कुछ मामलों में, सूचना डिलीवर करने के लिए FCM का इस्तेमाल नहीं किया जा सकता ज़रूरी या उचित.
उदाहरण के लिए, कैलेंडर इवेंट की सूचनाओं के लिए, स्थानीय टास्क को इससे आपका ऐप्लिकेशन सूचना भेजने के बजाय सही समय पर सूचना दिखाएगा इसे अपने ऐप्लिकेशन सर्वर से कॉपी करें. FCM मैसेज को कैलेंडर सिंक तक सीमित रखें.
बढ़ोतरी से बचें
एक स्केलिंग एंटी-पैटर्न है, FCM नोटिफ़िकेशन को सिस्टम जितनी तेज़ी से भेजता है सर्वर साइड थ्रॉटलिंग लागू करने के बजाय, इस सुविधा को अनुमति दें. इसके लिए, इन्हें आज़माएं:
- क्या आपके सभी ग्राहकों को एक मिनट की विंडो में एक ही सूचना मिलना ज़रूरी है? उदाहरण के लिए, क्या पांच मिनट की डिलीवरी विंडो अब भी आपके कारोबार की ज़रूरतें पूरी कर सकती है?
- क्या आपके ग्राहकों को प्राथमिकता के हिसाब से, समस्या को हल करने के लिए सेगमेंट में बांटा जा सकता है?
- क्या आपकी सूचनाएं समय से पहले शेड्यूल की जा सकती हैं?
जहां भी मुमकिन हो: ऐसी रणनीतियों से बचें जिनकी वजह से, FCM से भेजने का कोटा तुरंत खत्म हो जाता है. ऐसा सिर्फ़ तब करें, जब आपका टोकन बकेट रीफ़िल करते ही पैटर्न को दोहराया जाए. यह ऐक्सेस पैटर्न, FCM और इससे जुड़े आश्रित लोगों के लिए लोड-बैलेंसिंग की समस्याएं पैदा करता है सिस्टम. ट्रैफ़िक को जितना हो सके उतना धीरे-धीरे बढ़ाएं. कम से कम, रैंप 0 से 60 सेकंड की टाइम-विंडो में ज़्यादा से ज़्यादा आरपीएस. उच्च करने के लिए लंबी विंडो को प्राथमिकता दें आरपीएस.
"हर घंटे" का इस्तेमाल करने से बचें ट्रैफ़िक
जहां मुमकिन हो: इनमें से हर एक विंडो के दो मिनट के अंदर मैसेज भेजने से बचें :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% या थोड़ा छोटा. "सोच लो" (लोड के तहत सिस्टम के व्यवहार का पता लगाने के लिए) हर चरण को 1 दिन से 1 हफ़्ते तक देखें. इससे आपको अगले "चरण" से पहले संभावित समस्याओं का पता लगाने की सुविधा मिलती है
- ट्रैफ़िक में धीरे-धीरे बढ़ोतरी होना: हर "चरण" करते समय ट्रैफ़िक बढ़ाने के लिए, कम से कम एक घंटे के दौरान ट्रैफ़िक को कम किया जा सकता है. इससे FCM का लोड बैलेंसिंग इन्फ़्रास्ट्रक्चर, आपके नए ट्रैफ़िक को सही तरीके से बढ़ा पाता है. साथ ही, हॉटस्पॉट और भीड़ की संभावना को कम कर पाता है.
यहां 5,00,000 RPS को दुनिया भर में FCM एचटीटीपी v1 एपीआई के लिए FCM लेगसी एचटीटीपी एपीआई:
| हफ़्ता | चरण | रैंप-अप की धीरे-धीरे बढ़ने की रणनीति |
|---|---|---|
| 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 आरपीएस है.