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

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

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

Firebase के लिए कोटा चार हिस्सों में बांटा गया है:

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

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

  • समयसीमा

    इनसे यह तय होता है कि चीज़ें कितनी देर तक चल सकती हैं.

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

    इनसे, आपके फ़ंक्शन मैनेज करने के लिए, Firebase एपीआई को कॉल करने की दर पर असर पड़ता है.

  • नेटवर्किंग की सीमाएं

    इनसे आउटबाउंड कनेक्शन और इंस्टेंस की सीमाओं पर असर पड़ता है.

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

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

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

कोटा ब्यौरा Limit (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) की संख्या, मिली वीसीपीयू में. इसे एक मिनट की अवधि में, फ़ंक्शन इंस्टेंस के लिए उपयोगकर्ता से मिले सीपीयू के अनुरोधों के कुल योग से मेज़र किया जाता है. यह चुने गए इलाके पर निर्भर करता है. यह सीमा, ज़्यादा क्षमता वाले इलाकों में ज़्यादा हो सकती है या हाल ही में खोले गए इलाकों में कम हो सकती है. लागू नहीं हां हर प्रोजेक्ट और इलाके के हिसाब से

समयसीमा

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

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

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

नेटवर्किंग की सीमाएं

Firebase (दूसरी जनरेशन) नेटवर्किंग के अनुरोध और बैंडविड्थ की सीमाओं के बारे में जानकारी पाने के लिए, नेटवर्किंग की सीमाएं देखें.

Firebase (पहले जनरेशन) पर नेटवर्क से जुड़ी ये सीमाएं लागू होती हैं:

  • हर इंस्टेंस के लिए हर सेकंड में आउटबाउंड कनेक्शन: 500 (इसे बढ़ाया नहीं जा सकता)
  • हर इंस्टेंस के लिए, हर सेकंड में आउटबाउंड डीएनएस रिज़ॉल्यूशन: 100 (इसे बढ़ाया नहीं जा सकता)

बड़े पैमाने पर इस्तेमाल की जा सकने की सुविधा

एचटीटीपी से शुरू किए गए Firebase, आने वाले ट्रैफ़िक को मैनेज करने के लिए तेज़ी से स्केल अप करते हैं. वहीं, बैकग्राउंड फ़ंक्शन धीरे-धीरे स्केल अप करते हैं. किसी फ़ंक्शन को स्केल अप करने की क्षमता, इन बातों पर निर्भर करती है:

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

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

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

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

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

कोटा की तय सीमा पूरी होने पर

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

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

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

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

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

Firebase CLI का रेफ़रंस भी देखें.