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

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

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

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

Firebase के कोटे, चार तरह के होते हैं:

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

  इनसे तय होता है कि आपके फ़ंक्शन, कुल कितने संसाधन इस्तेमाल कर सकते हैं.

• समयसीमाएं

  इनसे तय होता है कि कोई चीज़ कितने समय तक चल सकती है.

• दर की सीमाएं

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

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

  इनसे आउटबाउंड कनेक्शन और इंस्टेंस की सीमाएं तय होती हैं.

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

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

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

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

ध्यान दें: अगर Pub/Sub का इस्तेमाल करके, किसी फ़ंक्शन को ट्रिगर किया जा रहा है, तो ध्यान रखें कि Pub/Sub मैसेज, base64 में एनकोड किए जाते हैं. ऐसा, इवेंट-ड्रिवन फ़ंक्शन या पुश सदस्यता के एचटीटीपी टारगेट के ज़रिए किया जा सकता है. Pub/Sub मैसेज का साइज़ ज़्यादा से ज़्यादा 10 एमबी हो सकता है. ज़्यादा से ज़्यादा साइज़ एनकोड करने के बाद, यह 10 एमबी से ज़्यादा हो जाता है. इसलिए, यह Cloud Functions की ज़्यादा से ज़्यादा साइज़ की सीमा से ज़्यादा हो सकता है.

समयसीमाएं

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

दर की सीमाएं

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

¹ WRITE कोटे को नहीं बढ़ाया जा सकता. आम तौर पर, कोटे की सीमा पूरी होने की वजह इनमें से कोई एक होती है:

• किसी सीआई/सीडी सिस्टम का इस्तेमाल करना यह सिस्टम, एक साथ या क्रम से, कई फ़ंक्शन को तेज़ी से डिप्लॉय करता है.
• एक साथ कई फ़ंक्शन डिप्लॉय करने के लिए, Firebase CLI का इस्तेमाल करना.

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

² CALL API सिर्फ़ Firebase (1st gen) पर लागू होता है. CALL कोटे को नहीं बढ़ाया जा सकता. आम तौर पर, कोटे की सीमा पूरी होने की वजह यह होती है कि प्रोडक्शन में अपने फ़ंक्शन को शुरू करने के लिए, गलती से इस एपीआई का इस्तेमाल किया गया हो. कृपया ध्यान रखें कि इस एपीआई का इस्तेमाल, Google Cloud Console या gcloud functions call CLI के साथ टेस्ट करने के लिए किया जाता है. यह ज़्यादा ट्रैफ़िक को हैंडल नहीं कर सकता.

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

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

Firebase (1st gen) पर, नेटवर्किंग की ये सीमाएं लागू होती हैं:

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

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

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

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

• ट्रांज़िएंट फ़ैक्टर, जैसे कि इलाके के हिसाब से लोड और डेटा सेंटर की क्षमता.

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

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

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

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

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

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

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

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

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

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