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