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