इस पेज पर, Cloud Functions के लिए, इस्तेमाल के आधार पर तय की गई बढ़ाने लायक सीमाओं के बारे में बताया गया है. ये सीमाएं, इस्तेमाल के हिसाब से पैसे चुकाएं वाले Blaze प्लान के मुताबिक तय की गई हैं. ये सीमाएं, उन Firebase प्रोजेक्ट पर लागू होती हैं जो Node.js 10 रनटाइम एनवायरमेंट में फ़ंक्शन डिप्लॉय करते हैं.
ब्लेज़ प्लान में, फ़ंक्शन को कॉल करने, कंप्यूट करने में लगने वाले समय, और इंटरनेट ट्रैफ़िक के लिए, बिना किसी शुल्क के ज़्यादा डेटा मिलता है. हालांकि, फ़ंक्शन डिप्लॉयमेंट के लिए, फ़ंक्शन के कंटेनर के लिए इस्तेमाल की गई स्टोरेज स्पेस के लिए कम शुल्क देना पड़ता है. ज़्यादा जानकारी के लिए, Firebase के अक्सर पूछे जाने वाले सवाल देखें.
Firebase के लिए कोटा चार तरह के होते हैं:
संसाधन की सीमाएं
इनसे, आपके फ़ंक्शन के इस्तेमाल किए जा सकने वाले संसाधनों की कुल संख्या पर असर पड़ता है.
समयसीमाएं
इनसे यह तय होता है कि कोई प्रोसेस कितने समय तक चल सकती है.
अनुरोध की संख्या सीमित है
इनसे, Firebase एपीआई को कॉल करने की दर पर असर पड़ता है, ताकि आपके फ़ंक्शन मैनेज किए जा सकें.
नेटवर्किंग की सीमाएं
इनसे आउटबाउंड कनेक्शन और इंस्टेंस की सीमाओं पर असर पड़ता है.
अलग-अलग तरह की सीमाओं के बारे में यहां ज़्यादा जानकारी दी गई है. जहां लागू हो वहां Firebase (1st gen) और Firebase (2nd gen) की सीमाओं के बीच अंतर बताया गया है.
संसाधन की सीमाएं
संसाधन की सीमाओं से, आपके फ़ंक्शन के इस्तेमाल किए जा सकने वाले संसाधनों की कुल संख्या पर असर पड़ता है. क्षेत्रीय स्कोप हर प्रोजेक्ट के हिसाब से होता है. साथ ही, हर प्रोजेक्ट के लिए सीमाएं अलग-अलग होती हैं.
| कोटा | ब्यौरा | Limit (1st gen) | Limit (2nd gen) | इसे बढ़ाया जा सकता है | दायरा |
|---|---|---|---|---|---|
| फ़ंक्शन की संख्या | हर क्षेत्र के लिए, डिप्लॉय किए जा सकने वाले फ़ंक्शन की कुल संख्या | 1,000 | 1,000 में से, Cloud Run सेवाओं की संख्या घटाकर | नहीं | हर क्षेत्र के हिसाब से |
| डिप्लॉयमेंट का ज़्यादा से ज़्यादा साइज़ | किसी फ़ंक्शन को डिप्लॉय करने का ज़्यादा से ज़्यादा साइज़ | सोर्स के लिए 100 एमबी (कंप्रेस की गई फ़ाइल). सोर्स और मॉड्यूल के लिए, 500 एमबी (कंप्रेस नहीं किया गया). |
लागू नहीं | नहीं | हर फ़ंक्शन के हिसाब से |
| अनकंप्रेस किए गए एचटीटीपी अनुरोध का ज़्यादा से ज़्यादा साइज़ | एचटीटीपी अनुरोध में, एचटीटीपी फ़ंक्शन को भेजा गया डेटा | 10 एमबी | 32 एमबी | नहीं | हर अनुरोध के लिए |
| अनकंप्रेस किए गए एचटीटीपी रिस्पॉन्स का ज़्यादा से ज़्यादा साइज़ | एचटीटीपी रिस्पॉन्स में, एचटीटीपी फ़ंक्शन से भेजा गया डेटा | 10 एमबी | स्ट्रीमिंग वाले जवाबों के लिए 10 एमबी. बिना स्ट्रीमिंग वाले जवाबों के लिए 32 एमबी. |
नहीं | हर अनुरोध के लिए |
| इवेंट ट्रिगर होने वाले फ़ंक्शन के लिए इवेंट का ज़्यादा से ज़्यादा साइज़ | बैकग्राउंड फ़ंक्शन को इवेंट में भेजा गया डेटा | 10 एमबी | Eventarc इवेंट के लिए 512 केबी. लेगसी इवेंट के लिए 10 एमबी. |
नहीं | हर इवेंट के लिए |
| फ़ंक्शन के लिए ज़्यादा से ज़्यादा मेमोरी | हर फ़ंक्शन इंस्टेंस के लिए मेमोरी की सीमा | 8GiB | 32GiB | नहीं | हर फ़ंक्शन के हिसाब से |
| प्रोजेक्ट के लिए तय की गई ज़्यादा से ज़्यादा मेमोरी | यह प्रोजेक्ट के लिए उपलब्ध मेमोरी की मात्रा है. यह बाइट में होती है. इसे एक मिनट की अवधि में, फ़ंक्शन इंस्टेंस के लिए उपयोगकर्ता की ओर से अनुरोध की गई मेमोरी की कुल रकम से मापा जाता है. | यह सुविधा, चुने गए इलाके के हिसाब से उपलब्ध होती है. ज़्यादा क्षमता वाले क्षेत्रों में यह सीमा ज़्यादा हो सकती है. वहीं, हाल ही में खुले क्षेत्रों में यह सीमा कम हो सकती है. | लागू नहीं | हां | हर प्रोजेक्ट और इलाके के हिसाब से |
| प्रोजेक्ट के लिए सीपीयू की ज़्यादा से ज़्यादा क्षमता | यह मिली वीसीपीयू में सीपीयू की वह मात्रा होती है जिसका इस्तेमाल कोई प्रोजेक्ट कर सकता है. इसे एक मिनट की अवधि में, फ़ंक्शन इंस्टेंस के लिए उपयोगकर्ता के अनुरोध किए गए सीपीयू की कुल संख्या से मापा जाता है. | यह सुविधा, चुने गए इलाके के हिसाब से उपलब्ध होती है. ज़्यादा क्षमता वाले क्षेत्रों में यह सीमा ज़्यादा हो सकती है. वहीं, हाल ही में खुले क्षेत्रों में यह सीमा कम हो सकती है. | लागू नहीं | हां | हर प्रोजेक्ट और इलाके के हिसाब से |
समयसीमाएं
| कोटा | ब्यौरा | Limit (1st gen) | Limit (2nd gen) | इसे बढ़ाया जा सकता है | दायरा |
|---|---|---|---|---|---|
| फ़ंक्शन की ज़्यादा से ज़्यादा अवधि | फ़ंक्शन को बंद करने से पहले, वह ज़्यादा से ज़्यादा कितनी देर तक चल सकता है | 540 सेकंड |
|
नहीं | हर अनुरोध के लिए |
अनुरोध की संख्या सीमित है
| कोटा | ब्यौरा | Limit (1st gen) | 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 एमबी | नहीं | हर फ़ंक्शन के हिसाब से | पहली और दूसरी जनरेशन |
कोटे की सीमा तक पहुंचने पर
जब कोई फ़ंक्शन, असाइन किए गए सभी संसाधनों का इस्तेमाल कर लेता है, तो संसाधन तब तक उपलब्ध नहीं होता, जब तक कोटा रीफ़्रेश या बढ़ाया नहीं जाता. इसका मतलब यह हो सकता है कि आपका फ़ंक्शन और उसी प्रोजेक्ट के सभी अन्य फ़ंक्शन तब तक काम नहीं करेंगे. जब कोई संसाधन कोटे से ज़्यादा हो जाता है और फ़ंक्शन को लागू नहीं किया जा सकता, तो फ़ंक्शन HTTP 500 गड़बड़ी कोड दिखाता है.
यहां दिए गए डिफ़ॉल्ट कोटे से ज़्यादा कोटे पाने के लिए, Firebase कोटे वाले पेज पर जाएं. इसके बाद, वे कोटे चुनें जिनमें आपको बदलाव करना है. इसके बाद, कोटे में बदलाव करें पर क्लिक करें. अगर आपसे उपयोगकर्ता की जानकारी मांगी जाती है, तो उसे दें. इसके बाद, चुने गए हर कोटे के लिए नई कोटा सीमा डालें.
Firebase CLI की मदद से डिप्लॉय करने के लिए कोटे की सीमाएं
Firebase CLI से डिप्लॉय किए गए हर फ़ंक्शन के लिए, दर और समय की इन सीमाओं पर असर पड़ता है:
- एपीआई कॉल (READ) - हर डिप्लॉयमेंट के लिए एक कॉल, भले ही फ़ंक्शन की संख्या कितनी भी हो
- सीमा: हर 100 सेकंड में 5,000
- एपीआई कॉल (WRITE) - हर फ़ंक्शन के लिए एक कॉल
- सीमा: हर 100 सेकंड में 80
Firebase CLI का रेफ़रंस भी देखें.