कोटा और सीमाएं

इस पेज पर, Cloud Functions के लिए इस्तेमाल के हिसाब से बढ़ाई जा सकने वाली सीमाओं की जानकारी दी गई है ब्लेज़ के हिसाब से पैसे चुकाएं. ये सीमाएं, उन Firebase प्रोजेक्ट पर लागू होती हैं जो Node.js 10 रनटाइम एनवायरमेंट में फ़ंक्शन डिप्लॉय करते हैं.

Blaze प्लान में बड़ी संख्या में लोगों को शामिल करने, कंप्यूट टाइम, और बिना किसी शुल्क के मिलने वाला इंटरनेट ट्रैफ़िक. हालांकि, फ़ंक्शन के कंटेनर के लिए इस्तेमाल किए गए स्टोरेज के लिए, फ़ंक्शन के डिप्लॉयमेंट पर कम शुल्क लिया जाता है. ज़्यादा जानकारी के लिए, Firebase के अक्सर पूछे जाने वाले सवाल देखें.

Google Cloud Functions का कोटा, तीन क्षेत्रों में उपलब्ध है:

  • संसाधन की सीमाएं

    इनसे आपके फ़ंक्शन के इस्तेमाल किए जा सकने वाले संसाधनों की कुल संख्या पर असर पड़ता है.

  • समयसीमाएं

    ये चीज़ें इस बात पर असर डालती हैं कि चीज़ें कितनी देर तक चलेंगी.

  • अनुरोध की संख्या सीमित है

    इनका असर उस दर पर पड़ता है जिस पर आप Cloud Functions API को कॉल कर सकते हैं अपने फ़ंक्शन को मैनेज करें.

अलग-अलग तरह की सीमाओं के बारे में नीचे ज़्यादा जानकारी दी गई है. Cloud Functions (1st gen) और Cloud Functions की सीमाओं के बीच अंतर ज़रूरत पड़ने पर Cloud Functions (2nd gen) नोट किया जाता है.

संसाधन की सीमाएं

संसाधन की सीमाएं, आपके फ़ंक्शन के इस्तेमाल किए जा सकने वाले संसाधनों की कुल संख्या पर असर डालती हैं. क्षेत्र के हिसाब से दायरा हर प्रोजेक्ट के लिए होता है और हर प्रोजेक्ट की अपनी सीमाएं होती हैं.

कोटा ब्यौरा सीमा (1st gen) Limit (2nd gen) बढ़ाया जा सकता है दायरा
फ़ंक्शन की संख्या हर क्षेत्र के हिसाब से डिप्लॉय किए जा सकने वाले फ़ंक्शन की कुल संख्या 1,000 डिप्लॉय की गई Cloud Run सेवाओं की संख्या को घटाकर 1,000 नहीं प्रति क्षेत्र
डिप्लॉयमेंट का ज़्यादा से ज़्यादा साइज़ किसी एक फ़ंक्शन के डिप्लॉयमेंट का ज़्यादा से ज़्यादा साइज़ सोर्स के लिए 100 एमबी (कंप्रेस की गई) .
सोर्स और मॉड्यूल के लिए 500 एमबी (बिना कंप्रेस की गई) वैल्यू.
लागू नहीं नहीं हर फ़ंक्शन के लिए
बिना कंप्रेस किए गए एचटीटीपी अनुरोध का ज़्यादा से ज़्यादा साइज़ एचटीटीपी अनुरोध में एचटीटीपी फ़ंक्शन को भेजा गया डेटा 10 एमबी 32 एमबी नहीं हर बार शुरू करने पर
एचटीटीपी रिस्पॉन्स का ज़्यादा से ज़्यादा साइज़, कंप्रेस न किया गया हो एचटीटीपी फ़ंक्शन से, एचटीटीपी रिस्पॉन्स में भेजा गया डेटा 10 एमबी जवाबों को स्ट्रीम करने के लिए 10 एमबी.
नॉन-स्ट्रीमिंग जवाबों के लिए 32 एमबी.
नहीं हर सवाल का जवाब
इवेंट-ड्रिवन फ़ंक्शन के लिए, इवेंट का ज़्यादा से ज़्यादा साइज़ इवेंट का डेटा, बैकग्राउंड फ़ंक्शन के लिए भेजा जाता है 10 एमबी Eventarc इवेंट के लिए 512 केबी.
लेगसी इवेंट के लिए 10 एमबी.
नहीं प्रति इवेंट
फ़ंक्शन मेमोरी की सबसे ज़्यादा वैल्यू हर फ़ंक्शन इंस्टेंस, कितनी मेमोरी का इस्तेमाल कर सकता है 8 गीगाबिट 32 जीबी नहीं हर फ़ंक्शन के लिए
प्रोजेक्ट मेमोरी की ज़्यादा से ज़्यादा सीमा 'इसके हिसाब से' में दी गई मेमोरी का वह हिस्सा जिसका इस्तेमाल किसी प्रोजेक्ट के लिए किया जा सकता है. इसे एक मिनट की अवधि में, फ़ंक्शन के सभी इंस्टेंस में उपयोगकर्ता के अनुरोध की गई मेमोरी के कुल योग से मापा जाता है. यह चुने गए इलाके पर निर्भर करता है. यह सीमा, ज़्यादा क्षमता वाले इलाकों में ज़्यादा हो सकती है या हाल ही में खोले गए इलाकों में कम हो सकती है. लागू नहीं हां हर प्रोजेक्ट और क्षेत्र के हिसाब से
मैक्स प्रोजेक्ट सीपीयू मिली vCPU में सीपीयू की संख्या, जिसका इस्तेमाल कोई प्रोजेक्ट कर सकता है. इसे एक मिनट की अवधि में, फ़ंक्शन के सभी इंस्टेंस में उपयोगकर्ता के अनुरोध किए गए सीपीयू की कुल संख्या से मापा जाता है. यह चुने गए क्षेत्र पर निर्भर करता है. यह सीमा, ज़्यादा क्षमता वाले इलाकों में ज़्यादा हो सकती है या हाल ही में खोले गए इलाकों में कम हो सकती है. लागू नहीं हां हर प्रोजेक्ट और क्षेत्र के हिसाब से

समयसीमाएं

कोटा ब्यौरा सीमा (1st gen) Limit (2nd gen) बढ़ाया जा सकता है दायरा
फ़ंक्शन के लिए ज़्यादा से ज़्यादा अवधि किसी फ़ंक्शन को ज़बरदस्ती खत्म किए जाने से पहले, उसके चलने का ज़्यादा से ज़्यादा समय 540 सेकंड एचटीटीपी फ़ंक्शन के लिए 60 मिनट.
इवेंट-ड्रिवन फ़ंक्शन के लिए 9 मिनट.
नहीं हर सवाल का जवाब

रेट लिमिट

कोटा ब्यौरा सीमा (1st gen) Limit (2nd gen) बढ़ाया जा सकता है दायरा
एपीआई कॉल (READ) Cloud Functions API का इस्तेमाल करके, फ़ंक्शन की जानकारी देने या उनकी सूची बनाने के लिए कॉल 5,000 प्रति 100 सेकंड हर 60 सेकंड में 1,200 सिर्फ़ पहले जनरेशन के लिए हर प्रोजेक्ट के लिए (1st gen)
हर क्षेत्र के हिसाब से (2nd gen)
एपीआई कॉल (लिखना) Cloud Functions API की मदद से फ़ंक्शन डिप्लॉय करने या मिटाने के लिए कॉल हर 100 सेकंड में 80 हर 60 सेकंड में 60 नहीं 1 हर प्रोजेक्ट के लिए (1st gen)
हर क्षेत्र के हिसाब से (2nd gen)
एपीआई कॉल (CALL) "कॉल" पर किए जाने वाले कॉल एपीआई हर 100 सेकंड में 16 लागू नहीं नहीं 2 प्रति प्रोजेक्ट

बढ़ाए जा सकने की योग्यता

एचटीटीपी से जिन Cloud Functions का इस्तेमाल किया जाता है उन्हें आने वाले ट्रैफ़िक को मैनेज करने के लिए तेज़ी से बढ़ाया जाता है, वहीं, बैकग्राउंड फ़ंक्शन की संख्या धीरे-धीरे बढ़ती है. फ़ंक्शन को स्केल करने की क्षमता आपके कॉन्टेंट पर कुछ असर पड़ता है. जैसे:

  • किसी फ़ंक्शन के निष्पादन को पूरा होने में लगने वाला समय (कम समय में चलने वाले फ़ंक्शन, आम तौर पर एक साथ चलने वाले ज़्यादा फ़ंक्शन को मैनेज करने के लिए स्केल अप कर सकते हैं अनुरोध).
  • कोल्ड स्टार्ट पर, किसी फ़ंक्शन को शुरू होने में लगने वाला समय.
  • आपके फ़ंक्शन की गड़बड़ी की दर.
  • अस्थायी कारक, जैसे कि रीजनल लोड और डेटा सेंटर की क्षमता.

बैकग्राउंड फ़ंक्शन में अतिरिक्त सीमाएं भी शामिल हैं, जैसा कि नीचे बताया गया है. ये सीमाएं 1st gen पर लागू नहीं होती हैं एचटीटीपी फ़ंक्शन.

बैकग्राउंड फ़ंक्शन के लिए अतिरिक्त कोटा

कोटा ब्यौरा सीमा बढ़ाया जा सकता है दायरा प्रॉडक्ट का वर्शन
ज़्यादा से ज़्यादा एक साथ शुरू किए जाने वाले किसी एक फ़ंक्शन के एक साथ शुरू किए जाने वाले ज़्यादा से ज़्यादा
उदाहरण: अगर हर इवेंट को मैनेज करने में 100 सेकंड लगते हैं, तो यह दर औसतन 30 प्रति सेकंड तक सीमित रहेगी
3,000 हां हर फ़ंक्शन के लिए सिर्फ़ पहली पीढ़ी के लिए
शुरू करने की ज़्यादा से ज़्यादा दर किसी एक फ़ंक्शन से मैनेज किए जा रहे इवेंट की ज़्यादा से ज़्यादा दर
उदाहरण: अगर किसी इवेंट को मैनेज करने में 100 मि॰से॰ लगते हैं, तो दर 1000 प्रति सेकंड तक सीमित रहेगी, भले ही केवल 100 अनुरोध ही क्यों न किए गए हों, औसतन, एक साथ हैंडल किए जाते हैं
1,000 प्रति सेकंड नहीं हर फ़ंक्शन के लिए सिर्फ़ 1st gen
एक साथ इवेंट डेटा का ज़्यादा से ज़्यादा साइज़ इनकमिंग इवेंट का अधिकतम कुल आकार सिंगल फ़ंक्शन
उदाहरण: अगर इवेंट का साइज़ 1 एमबी है और उन्हें प्रोसेस करने में 10 बार लगते हैं सेकंड है, तो औसत दर 1 इवेंट प्रति सेकंड होगी, क्योंकि 11वां इवेंट को तब तक प्रोसेस नहीं किया जाएगा, जब तक पहले 10 इवेंट में से किसी एक को प्रोसेस नहीं किया जाता समाप्त
10 एमबी नहीं हर फ़ंक्शन के लिए 1st gen और 2nd gen
इनकमिंग इवेंट की ज़्यादा से ज़्यादा थ्रूपुट किसी एक फ़ंक्शन के लिए, इनकमिंग इवेंट की ज़्यादा से ज़्यादा थ्रूपुट जानकारी
उदाहरण: अगर इवेंट का साइज़ 1 एमबी है, तो इवेंट शुरू करने की दर यह दर हर सेकंड ज़्यादा से ज़्यादा 10 होनी चाहिए, भले ही फ़ंक्शन 100 मि॰से॰ के अंदर पूरा हो गया हो
हर सेकंड 10 एमबी नहीं हर फ़ंक्शन के लिए 1st gen और 2nd gen

जब आपका कोटे की तय सीमा पूरी हो जाती है

जब कोई फ़ंक्शन एक असाइन किए गए सभी संसाधन का इस्तेमाल करता है, तो संसाधन कोटा को रीफ़्रेश या बढ़ाने तक, उसका इस्तेमाल नहीं किया जा सकता. इसका मतलब यह हो सकता है कि तब तक आपका फ़ंक्शन और उसी प्रोजेक्ट के अन्य सभी फ़ंक्शन काम नहीं करेंगे. जब कोई एक संसाधन ऐसा होता है, तो फ़ंक्शन एचटीटीपी 500 गड़बड़ी कोड दिखाता है कोटा से ज़्यादा है और फ़ंक्शन एक्ज़ीक्यूट नहीं किया जा सकता.

कोटा को ऊपर दी गई डिफ़ॉल्ट सूची से बढ़ाने के लिए, यहां जाएं Cloud Functions कोटा का पेज, वे कोटा चुनें जिनमें आप बदलाव करना चाहते हैं. इसके बाद, क्लिक करें कोटा में बदलाव करें, पूछे जाने पर उपयोगकर्ता की जानकारी दें, और नया आपके चुने गए हर कोटे के लिए कोटे की सीमा.

Firebase सीएलआई डिप्लॉयमेंट के लिए कोटा की सीमाएं

Firebase CLI से डिप्लॉय किए गए हर फ़ंक्शन के लिए, इन तरह के रेट और समयसीमाओं पर असर पड़ता है:

  • एपीआई कॉल (READ) - हर डिप्लॉयमेंट के लिए एक कॉल, चाहे कितने भी फ़ंक्शन हों
    • सीमा: हर 100 सेकंड में 5,000
  • एपीआई कॉल (लिखना) - हर फ़ंक्शन के लिए एक कॉल
    • सीमा: हर 100 सेकंड में 80

Firebase सीएलआई का रेफ़रंस भी देखें.