इस पेज पर, ब्लेज़ प्लान के तहत इस्तेमाल के हिसाब से पैसे चुकाने वाले प्लान के मुताबिक, Cloud Functions के लिए इस्तेमाल के हिसाब से तय की गई सीमाओं के बारे में जानकारी दी गई है. ये सीमाएं, उन Firebase प्रोजेक्ट पर लागू होती हैं जो Node.js 10 रनटाइम एनवायरमेंट में फ़ंक्शन डिप्लॉय करते हैं.
ब्लेज़ प्लान में, आपको बिना किसी शुल्क के ज़्यादा से ज़्यादा बार फ़ंक्शन कॉल करने, कंप्यूट टाइम, और इंटरनेट ट्रैफ़िक की सुविधा मिलती है. हालांकि, फ़ंक्शन डिप्लॉयमेंट के लिए, फ़ंक्शन के कंटेनर के लिए इस्तेमाल की गई स्टोरेज स्पेस के लिए कम शुल्क लगता है. ज़्यादा जानकारी के लिए, Firebase के अक्सर पूछे जाने वाले सवाल देखें.
Firebase के लिए कोटा में चार चीज़ें शामिल हैं:
संसाधन की सीमाएं
इनसे, आपके फ़ंक्शन के इस्तेमाल किए जा सकने वाले संसाधनों की कुल संख्या पर असर पड़ता है.
समयसीमाएं
इनसे यह तय होता है कि कोई प्रोसेस कितने समय तक चल सकती है.
अनुरोध की संख्या सीमित है
इनसे, Firebase एपीआई को कॉल करने की दर पर असर पड़ता है, ताकि आपके फ़ंक्शन मैनेज किए जा सकें.
नेटवर्किंग की सीमाएं
इनसे आउटबाउंड कनेक्शन और इंस्टेंस की सीमाओं पर असर पड़ता है.
अलग-अलग तरह की सीमाओं के बारे में यहां ज़्यादा जानकारी दी गई है. जहां ज़रूरी है वहां Firebase (1st gen) और Firebase (2nd gen) की सीमाओं के बीच के अंतर के बारे में बताया गया है.
संसाधन की सीमाएं
संसाधन की सीमाओं से, आपके फ़ंक्शन के इस्तेमाल किए जा सकने वाले संसाधनों की कुल संख्या पर असर पड़ता है. क्षेत्रीय स्कोप हर प्रोजेक्ट के हिसाब से होता है. साथ ही, हर प्रोजेक्ट की अपनी सीमाएं होती हैं.
| कोटा | ब्यौरा | सीमा (1st जनरेशन) | Limit (2nd gen) | इसे बढ़ाया जा सकता है | दायरा |
|---|---|---|---|---|---|
| फ़ंक्शन की संख्या | हर क्षेत्र के लिए, डिप्लॉय किए जा सकने वाले फ़ंक्शन की कुल संख्या | 1,000 | Cloud Run सेवाओं को डिप्लॉय करने की संख्या को 1,000 में से घटाकर | नहीं | हर क्षेत्र के हिसाब से |
| डिप्लॉयमेंट का ज़्यादा से ज़्यादा साइज़ | किसी फ़ंक्शन को डिप्लॉय करने के लिए ज़्यादा से ज़्यादा साइज़ | सोर्स के लिए 100 एमबी (कंप्रेस की गई फ़ाइल). सोर्स और मॉड्यूल के लिए, बिना कंप्रेस किए गए डेटा का साइज़ 500 एमबी होना चाहिए. |
लागू नहीं | नहीं | हर फ़ंक्शन के हिसाब से |
| अनकंप्रेस किए गए एचटीटीपी अनुरोध का ज़्यादा से ज़्यादा साइज़ | एचटीटीपी अनुरोध में एचटीटीपी फ़ंक्शन को भेजा गया डेटा | 10 एमबी | 32 एमबी | नहीं | हर अनुरोध के लिए |
| अनकंप्रेस किए गए एचटीटीपी रिस्पॉन्स का ज़्यादा से ज़्यादा साइज़ | एचटीटीपी रिस्पॉन्स में, एचटीटीपी फ़ंक्शन से भेजा गया डेटा | 10 एमबी | जवाबों को स्ट्रीम करने के लिए 10 एमबी. स्ट्रीमिंग के बिना जवाबों के लिए 32 एमबी. |
नहीं | हर अनुरोध के लिए |
| इवेंट ट्रिगर होने वाले फ़ंक्शन के लिए इवेंट का ज़्यादा से ज़्यादा साइज़ | बैकग्राउंड फ़ंक्शन को इवेंट में भेजा गया डेटा | 10 एमबी | Eventarc इवेंट के लिए 512 केबी. लेगसी इवेंट के लिए 10 एमबी. |
नहीं | हर इवेंट के लिए |
| फ़ंक्शन के लिए ज़्यादा से ज़्यादा मेमोरी | हर फ़ंक्शन इंस्टेंस कितनी मेमोरी का इस्तेमाल कर सकता है | 8GiB | 32GiB | नहीं | हर फ़ंक्शन के हिसाब से |
| प्रोजेक्ट के लिए ज़्यादा से ज़्यादा मेमोरी | यह किसी प्रोजेक्ट के लिए उपलब्ध मेमोरी की मात्रा है. इसकी यूनिट बाइट (B) है. इसे एक मिनट की अवधि में, फ़ंक्शन इंस्टेंस के लिए उपयोगकर्ता की ओर से अनुरोध की गई मेमोरी की कुल रकम से मापा जाता है. | यह सुविधा, चुने गए इलाके के हिसाब से उपलब्ध होती है. ज़्यादा क्षमता वाले क्षेत्रों में यह सीमा ज़्यादा हो सकती है. वहीं, हाल ही में खुले क्षेत्रों में यह सीमा कम हो सकती है. | लागू नहीं | हां | हर प्रोजेक्ट और इलाके के हिसाब से |
| प्रोजेक्ट के लिए सीपीयू की ज़्यादा से ज़्यादा क्षमता | यह किसी प्रोजेक्ट के लिए उपलब्ध सीपीयू की संख्या होती है. इसे मिली वीसीपीयू में मापा जाता है. इसे एक मिनट की अवधि में, फ़ंक्शन इंस्टेंस के लिए उपयोगकर्ता के अनुरोध किए गए सीपीयू के कुल योग से मापा जाता है. | यह सुविधा, चुने गए इलाके के हिसाब से उपलब्ध होती है. ज़्यादा क्षमता वाले क्षेत्रों में यह सीमा ज़्यादा हो सकती है. वहीं, हाल ही में खुले क्षेत्रों में यह सीमा कम हो सकती है. | लागू नहीं | हां | हर प्रोजेक्ट और इलाके के हिसाब से |
समयसीमाएं
| कोटा | ब्यौरा | सीमा (1st जनरेशन) | Limit (2nd gen) | इसे बढ़ाया जा सकता है | दायरा |
|---|---|---|---|---|---|
| फ़ंक्शन की ज़्यादा से ज़्यादा अवधि | फ़ंक्शन को ज़बरदस्ती बंद करने से पहले, वह ज़्यादा से ज़्यादा कितनी देर तक चल सकता है | 540 सेकंड |
|
नहीं | हर अनुरोध के लिए |
अनुरोध की संख्या सीमित है
| कोटा | ब्यौरा | सीमा (1st जनरेशन) | Limit (2nd gen) | इसे बढ़ाया जा सकता है | दायरा |
|---|---|---|---|---|---|
| एपीआई कॉल (READ) | Firebase API के ज़रिए, फ़ंक्शन के बारे में बताने या उन्हें लिस्ट करने के लिए कॉल | हर 100 सेकंड में 5,000 | 60 सेकंड में 1200 | सिर्फ़ पहली जनरेशन के लिए | हर प्रोजेक्ट के लिए (1st gen) हर इलाके के लिए (2nd gen) |
| एपीआई कॉल (WRITE) | Firebase एपीआई के ज़रिए फ़ंक्शन को डिप्लॉय या मिटाने के लिए किए गए कॉल | 100 सेकंड में 80 | 60 प्रति 60 सेकंड | नहीं 1 | हर प्रोजेक्ट के लिए (1st gen) हर इलाके के लिए (2nd gen) |
| एपीआई कॉल (CALL) | "call" एपीआई को किए गए कॉल | 100 सेकंड में 16 | लागू नहीं | नहीं 2 | हर प्रोजेक्ट के लिए |
नेटवर्किंग की सीमाएं
Firebase (दूसरी जनरेशन) के नेटवर्किंग अनुरोध और बैंडविड्थ की सीमाओं के बारे में जानने के लिए, नेटवर्किंग की सीमाएं लेख पढ़ें.
Firebase (पहली जनरेशन) पर ये नेटवर्किंग सीमाएं लागू होती हैं:
- हर इंस्टेंस के लिए, हर सेकंड में आउटबाउंड कनेक्शन: 500 (इसे बढ़ाया नहीं जा सकता)
- हर इंस्टेंस के लिए, हर सेकंड में आउटबाउंड डीएनएस रिज़ॉल्यूशन: 100 (इसे बढ़ाया नहीं जा सकता)
- हर इंस्टेंस के लिए, हर सेकंड ज़्यादा से ज़्यादा पैकेट: 80,000
- हर इंस्टेंस के लिए, ज़्यादा से ज़्यादा बिट प्रति सेकंड: 10,00,00,000
बढ़ाए जा सकने की योग्यता
Firebase को एचटीटीपी अनुरोधों के हिसाब से तुरंत बढ़ाया जा सकता है, ताकि आने वाले ट्रैफ़िक को मैनेज किया जा सके. वहीं, बैकग्राउंड फ़ंक्शन को धीरे-धीरे बढ़ाया जाता है. किसी फ़ंक्शन को स्केल अप करने की क्षमता, इन बातों पर निर्भर करती है:
- किसी फ़ंक्शन को पूरा होने में लगने वाला समय (कम समय में पूरे होने वाले फ़ंक्शन, एक साथ कई अनुरोधों को हैंडल कर सकते हैं).
- कोल्ड स्टार्ट के दौरान, किसी फ़ंक्शन को शुरू होने में लगने वाला समय.
- आपके फ़ंक्शन की गड़बड़ी की दर.
कुछ समय के लिए होने वाले बदलाव, जैसे कि क्षेत्र के हिसाब से लोड और डेटा सेंटर की क्षमता.
बैकग्राउंड में चलने वाले फ़ंक्शन के लिए अतिरिक्त कोटा
| कोटा | ब्यौरा | सीमा | इसे बढ़ाया जा सकता है | दायरा | प्रॉडक्ट का वर्शन |
|---|---|---|---|---|---|
| एक साथ ज़्यादा से ज़्यादा कॉल किए जा सकते हैं | किसी फ़ंक्शन को एक साथ ज़्यादा से ज़्यादा कितनी बार कॉल किया जा सकता है उदाहरण: अगर हर इवेंट को हैंडल करने में 100 सेकंड लगते हैं, तो कॉल करने की दर औसतन 30 बार प्रति सेकंड तक सीमित होगी |
3,000 | हां | हर फ़ंक्शन के हिसाब से | सिर्फ़ पहली जनरेशन के लिए |
| फ़ंक्शन को कॉल करने की ज़्यादा से ज़्यादा दर | किसी फ़ंक्शन के ज़रिए हैंडल किए जा रहे इवेंट की ज़्यादा से ज़्यादा दर उदाहरण: अगर किसी इवेंट को हैंडल करने में 100 मि॰से॰ लगते हैं, तो इनवॉकेशन की दर एक सेकंड में 1,000 तक सीमित हो जाएगी. भले ही, औसतन सिर्फ़ 100 अनुरोधों को एक साथ हैंडल किया जा रहा हो |
हर सेकंड में 1,000 | नहीं | हर फ़ंक्शन के हिसाब से | सिर्फ़ पहली जनरेशन के लिए |
| एक साथ होने वाले इवेंट के डेटा का ज़्यादा से ज़्यादा साइज़ | एक फ़ंक्शन के एक साथ कई बार इस्तेमाल किए जाने पर, आने वाले इवेंट का कुल साइज़ ज़्यादा से ज़्यादा इतना हो सकता है उदाहरण: अगर इवेंट का साइज़ 1 एमबी है और उन्हें प्रोसेस करने में 10 सेकंड लगते हैं, तो औसत दर एक इवेंट प्रति सेकंड होगी. ऐसा इसलिए, क्योंकि पहले 10 इवेंट में से किसी एक के प्रोसेस होने तक, 11वें इवेंट को प्रोसेस नहीं किया जाएगा |
10 एमबी | नहीं | हर फ़ंक्शन के हिसाब से | पहली और दूसरी जनरेशन |
| इनकमिंग इवेंट का ज़्यादा से ज़्यादा थ्रूपुट | किसी फ़ंक्शन में आने वाले इवेंट का ज़्यादा से ज़्यादा थ्रूपुट उदाहरण: अगर इवेंट का साइज़ 1 एमबी है, तो इनवॉकेशन रेट ज़्यादा से ज़्यादा 10 प्रति सेकंड हो सकता है. भले ही, फ़ंक्शन 100 मि॰से॰ में पूरे हो जाएं |
हर सेकंड में 10 एमबी | नहीं | हर फ़ंक्शन के हिसाब से | पहली और दूसरी जनरेशन |
कोटे की सीमा तक पहुंचने पर
जब कोई फ़ंक्शन, असाइन किए गए सभी संसाधनों का इस्तेमाल कर लेता है, तो संसाधन तब तक उपलब्ध नहीं होता, जब तक कोटा रीफ़्रेश नहीं हो जाता या बढ़ नहीं जाता. इसका मतलब यह हो सकता है कि आपका फ़ंक्शन और उसी प्रोजेक्ट के अन्य सभी फ़ंक्शन, तब तक काम नहीं करेंगे. जब कोई संसाधन कोटे से ज़्यादा हो जाता है और फ़ंक्शन को लागू नहीं किया जा सकता, तो फ़ंक्शन एचटीटीपी 500 गड़बड़ी कोड दिखाता है.
यहां दिए गए डिफ़ॉल्ट कोटे से ज़्यादा कोटे पाने के लिए, Firebase कोटे वाले पेज पर जाएं. इसके बाद, वे कोटे चुनें जिनमें आपको बदलाव करना है. इसके बाद, कोटे में बदलाव करें पर क्लिक करें. अगर आपसे उपयोगकर्ता की जानकारी मांगी जाती है, तो उसे दें. इसके बाद, चुने गए हर कोटे के लिए नई कोटा सीमा डालें.
Firebase CLI की मदद से डिप्लॉय करने के लिए कोटे की सीमाएं
Firebase CLI से डिप्लॉय किए गए हर फ़ंक्शन के लिए, दर और समय की इन सीमाओं पर असर पड़ता है:
- एपीआई कॉल (READ) - हर डिप्लॉयमेंट के लिए एक कॉल, भले ही फ़ंक्शन की संख्या कितनी भी हो
- सीमा: हर 100 सेकंड में 5,000
- एपीआई कॉल (WRITE) - हर फ़ंक्शन के लिए एक कॉल
- सीमा: हर 100 सेकंड में 80
Firebase CLI का रेफ़रंस भी देखें.