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