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