हमारा मकसद, FCM का इस्तेमाल करके भेजे गए हर मैसेज को डिलीवर करना है. हालांकि, हर मैसेज डिलीवर करने से कभी-कभी उपयोगकर्ता अनुभव खराब हो जाता है. अन्य मामलों में, हमें सीमाएं तय करनी होती हैं, ताकि यह पक्का किया जा सके कि FCM, सभी सेंडर के लिए एक जैसी सेवा उपलब्ध कराता है. इस सेक्शन में बताई गई सीमाएं और कोटा, इन अहम फ़ैक्टर को संतुलित करने में हमारी मदद करते हैं.
डाउनस्ट्रीम मैसेज थ्रॉटलिंग
HTTP v1 API ने डाउनस्ट्रीम मैसेजिंग के लिए, हर प्रोजेक्ट के लिए हर मिनट के हिसाब से कोटा तय किया है. हर मिनट 600,000 मैसेज भेजने की डिफ़ॉल्ट सीमा, 99% से ज़्यादा FCM डेवलपर के लिए काफ़ी है. इससे सिस्टम की स्थिरता बनी रहती है और अचानक बढ़ने वाले प्रोजेक्ट पर असर कम पड़ता है.
ट्रैफ़िक में अचानक बढ़ोतरी होने पर, कोटा पूरा होने से जुड़ी गड़बड़ियां दिख सकती हैं. कोटा खत्म होने पर, सिस्टम अगले मिनट तक HTTP स्टेटस कोड 429 (QUOTA_EXCEEDED) दिखाता है. सर्वर पर ज़्यादा लोड होने की वजह से भी 429 रिस्पॉन्स मिल सकते हैं. इसलिए, हमारा सुझाव है कि आप पब्लिश किए गए सुझावों के मुताबिक, 429 रिस्पॉन्स को मैनेज करें.
ध्यान दें कि:
- डाउनस्ट्रीम कोटा, अनुरोधों के बजाय मैसेज को मेज़र करता है.
- क्लाइंट की गड़बड़ियों (एचटीटीपी स्टेटस कोड 400-499) को गिना जाता है. हालांकि, 429 को छोड़कर.
- कोटा हर मिनट के हिसाब से तय किए जाते हैं. हालांकि, ये मिनट घड़ी के हिसाब से नहीं होते.
मॉनिटरिंग कोटा
Google Cloud Console पर, अनुरोध भेजने की सीमा, इस्तेमाल, और गड़बड़ियां देखी जा सकती हैं:
- Google Cloud कंसोल पर जाएं
- एपीआई और सेवाएं को चुनें
- टेबल की सूची से, Firebase Cloud Messaging API चुनें
- कोटा और सिस्टम की सीमाएं को चुनें.
ध्यान दें: ये ग्राफ़, कोटा मिनट के साथ सटीक तौर पर अलाइन नहीं होते. इसका मतलब है कि जब ट्रैफ़िक, कोटा के हिसाब से कम दिखता है, तब भी 429 गड़बड़ियां दिख सकती हैं.
कोटा बढ़ाने का अनुरोध करना
कोटा बढ़ाने का अनुरोध करने से पहले, पक्का करें कि:
- आपका इस्तेमाल, लगातार पांच मिनट तक हर दिन कोटे का 80% या इससे ज़्यादा हो.
- आपके पास क्लाइंट की गड़बड़ी का अनुपात 5% से कम हो. खास तौर पर, पीक ट्रैफ़िक के दौरान.
- आपने एक साथ कई मैसेज भेजने के सबसे सही तरीके अपनाए हों.
अगर आपने इन शर्तों को पूरा किया है, तो कोटा बढ़ाने का अनुरोध सबमिट करें. इसके लिए, ज़्यादा से ज़्यादा +25% का अनुरोध किया जा सकता है. FCM, अनुरोध को पूरा करने के लिए हर संभव कोशिश करेगा. हालांकि, कोटा बढ़ाने की गारंटी नहीं दी जा सकती.
अगर आपको किसी लॉन्च या कुछ समय के लिए होने वाले इवेंट की वजह से, डाउनस्ट्रीम मैसेजिंग के लिए ज़्यादा कोटा चाहिए, तो कोटा पाने का अनुरोध कम से कम 15 दिन पहले करें. इससे हमें अनुरोध को पूरा करने के लिए काफ़ी समय मिल जाएगा. बड़े अनुरोधों (हर मिनट 1.8 करोड़ से ज़्यादा मैसेज) के लिए, कम से कम 30 दिन पहले सूचना देना ज़रूरी है. लॉन्च और खास इवेंट के अनुरोधों पर, अब भी क्लाइंट की गड़बड़ी के अनुपात और सबसे सही तरीकों से जुड़ी ज़रूरी शर्तें लागू होती हैं.
FCM कोटा के बारे में अक्सर पूछे जाने वाले सवाल भी देखें.
विषय के हिसाब से मैसेज भेजने की सीमा
किसी विषय की सदस्यता जोड़ने या हटाने की दर, हर प्रोजेक्ट के लिए 3,000 क्यूपीएस तक सीमित है.
मैसेज भेजने की दरों के बारे में जानने के लिए, फ़ैनआउट थ्रॉटलिंग देखें.
डुप्लीकेट डेटा की गड़बड़ी के लिए थ्रॉटलिंग
मैसेज फ़ैनआउट, एक मैसेज को कई डिवाइसों पर भेजने की प्रोसेस है. जैसे, जब टॉपिक और ग्रुप को टारगेट किया जाता है या जब ऑडियंस या उपयोगकर्ता सेगमेंट को टारगेट करने के लिए, सूचना कंपोज़र का इस्तेमाल किया जाता है.
मैसेज फ़ैनआउट तुरंत नहीं होता है. इसलिए, कभी-कभी एक साथ कई फ़ैनआउट प्रोसेस में होते हैं. हम हर प्रोजेक्ट के लिए, एक साथ भेजे जाने वाले मैसेज की संख्या को 1,000 तक सीमित रखते हैं. इसके बाद, हम फ़ैनआउट के अन्य अनुरोधों को अस्वीकार कर सकते हैं या फ़ैनआउट के अनुरोधों को तब तक के लिए रोक सकते हैं, जब तक कि पहले से चल रहे कुछ फ़ैनआउट पूरे न हो जाएं.
फ़ैनआउट करने की असल दर पर, उन प्रोजेक्ट की संख्या का असर पड़ता है जो एक ही समय में फ़ैनआउट करने का अनुरोध करते हैं. किसी एक प्रोजेक्ट के लिए, 10,000 क्यूपीएस की फ़ैनआउट दर आम बात है. हालांकि, यह संख्या गारंटी नहीं है और यह सिस्टम पर मौजूद कुल लोड का नतीजा है. यह ध्यान रखना ज़रूरी है कि फ़ैनआउट के लिए उपलब्ध क्षमता को प्रोजेक्ट के हिसाब से बांटा जाता है, न कि फ़ैनआउट के अनुरोधों के हिसाब से. इसलिए, अगर आपके प्रोजेक्ट में दो फ़ैनआउट चल रहे हैं, तो हर फ़ैनआउट को फ़ैनआउट रेट का सिर्फ़ आधा हिस्सा दिखेगा. हमारा सुझाव है कि एक बार में सिर्फ़ एक फ़ैनआउट प्रोसेस चालू रखें. इससे फ़ैनआउट की स्पीड को ज़्यादा से ज़्यादा किया जा सकता है.
मैसेज थ्रॉटलिंग को छोटा किया जा सकता है
छोटे किए जा सकने वाले मैसेज में बताया गया है कि ये ऐसे सूचनाएं होती हैं जिनमें कोई कॉन्टेंट नहीं होता. इन्हें एक-दूसरे के ऊपर छोटा करके दिखाया जाता है. अगर कोई डेवलपर किसी ऐप्लिकेशन को बार-बार एक ही मैसेज भेजता है, तो हम मैसेज भेजने में देरी करते हैं. इससे, उपयोगकर्ता के डिवाइस की बैटरी पर पड़ने वाले असर को कम किया जा सकता है.
उदाहरण के लिए, अगर किसी एक डिवाइस पर ईमेल सिंक करने के लिए कई नए अनुरोध भेजे जाते हैं, तो हम अगले ईमेल सिंक करने के अनुरोध को कुछ मिनटों के लिए रोक सकते हैं. इससे डिवाइस, कम औसत दर पर सिंक हो पाएगा. इस थ्रॉटलिंग को सिर्फ़ इसलिए किया जाता है, ताकि उपयोगकर्ता को बैटरी पर पड़ने वाले असर को कम किया जा सके.
अगर आपको एक साथ कई मैसेज भेजने हैं, तो हो सकता है कि नॉन-कोलैप्स होने वाले मैसेज आपके लिए सही विकल्प हों. ऐसे मैसेज के लिए, यह पक्का करें कि उनमें कॉन्टेंट शामिल हो, ताकि बैटरी की खपत कम हो.
हम हर ऐप्लिकेशन के लिए, हर डिवाइस पर ज़्यादा से ज़्यादा 20 छोटे किए जा सकने वाले मैसेज भेज सकते हैं. इसके बाद, हर तीन मिनट में एक मैसेज भेजा जा सकता है.
किसी एक डिवाइस पर मैसेज भेजने की ज़्यादा से ज़्यादा दर
Android पर, एक डिवाइस से हर मिनट ज़्यादा से ज़्यादा 240 मैसेज और हर घंटे ज़्यादा से ज़्यादा 5,000 मैसेज भेजे जा सकते हैं. इस थ्रेशोल्ड को ज़्यादा इसलिए रखा गया है, ताकि कम समय में ट्रैफ़िक में अचानक होने वाली बढ़ोतरी को मैनेज किया जा सके. जैसे, जब उपयोगकर्ता चैट पर तेज़ी से इंटरैक्ट कर रहे हों. इस सीमा की वजह से, डिवाइस की बैटरी खत्म होने से जुड़ी गड़बड़ियां नहीं होती हैं.
iOS के लिए, जब दर APNs की सीमाओं से ज़्यादा हो जाती है, तो हम गड़बड़ी का मैसेज दिखाते हैं.