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