Firebase CLI कमांड का इस्तेमाल करके या अपने फ़ंक्शन के सोर्स कोड में रनटाइम के विकल्प सेट करके, फ़ंक्शन को डिप्लॉय, मिटाया, और बदला जा सकता है.
फ़ंक्शन डिप्लॉय करना
फ़ंक्शन डिप्लॉय करने के लिए, यह Firebase CLI कमांड चलाएं:
firebase deploy --only functions
डिफ़ॉल्ट रूप से, Firebase CLI आपके सोर्स में मौजूद सभी फ़ंक्शन को एक साथ डिप्लॉय करता है. अगर आपके प्रोजेक्ट में पांच से ज़्यादा फ़ंक्शन हैं, तो हमारा सुझाव है कि आप --only
फ़्लैग का इस्तेमाल करें. साथ ही, उन फ़ंक्शन के नाम डालें जिन्हें आपको डिप्लॉय करना है. इससे सिर्फ़ वे फ़ंक्शन डिप्लॉय होंगे जिन्हें आपने बदला है. कुछ फ़ंक्शन डिप्लॉय करना
इस तरीके से डिप्लॉयमेंट की प्रोसेस तेज़ हो जाती है. साथ ही, डिप्लॉयमेंट कोटे से जुड़ी समस्याओं से बचने में मदद मिलती है. उदाहरण के लिए:
firebase deploy --only functions:addMessage,functions:makeUppercase
बहुत ज़्यादा फ़ंक्शन डिप्लॉय करने पर, हो सकता है कि आप स्टैंडर्ड कोटे से ज़्यादा फ़ंक्शन डिप्लॉय कर दें. ऐसे में, आपको एचटीटीपी 429 या 500 गड़बड़ी के मैसेज मिल सकते हैं. इस समस्या को हल करने के लिए, फ़ंक्शन को 10 या उससे कम के ग्रुप में डिप्लॉय करें.
उपलब्ध कमांड की पूरी सूची देखने के लिए, Firebase सीएलआई रेफ़रंस देखें.
डिफ़ॉल्ट रूप से, Firebase सीएलआई, सोर्स कोड के लिए functions/
फ़ोल्डर में देखता है. अगर आपको पसंद है, तो कोडबेस या फ़ाइलों के कई सेट में फ़ंक्शन व्यवस्थित किए जा सकते हैं.
डिप्लॉयमेंट आर्टफ़ैक्ट मिटाना
फ़ंक्शन डिप्लॉयमेंट के हिस्से के तौर पर, कंटेनर इमेज जनरेट की जाती हैं और Artifact Registry में सेव की जाती हैं. इन इमेज की ज़रूरत, डिप्लॉय किए गए फ़ंक्शन को चलाने के लिए नहीं होती; Cloud Functions यह इमेज की कॉपी को शुरुआती डिप्लॉयमेंट पर फ़ेच करता है और उसे सेव रखता है. हालांकि, सेव किए गए आर्टफ़ैक्ट, फ़ंक्शन को रनटाइम पर चलाने के लिए ज़रूरी नहीं होते.
ये कंटेनर इमेज अक्सर छोटी होती हैं. हालांकि, समय के साथ इनकी संख्या बढ़ सकती है और ये आपके स्टोरेज की लागत में योगदान दे सकती हैं. अगर आपको बनाए गए आर्टफ़ैक्ट की जांच करनी है या कंटेनर की कमज़ोरियों को स्कैन करना है, तो हो सकता है कि आपको उन्हें कुछ समय के लिए सेव रखना पड़े.
स्टोरेज की लागत को मैनेज करने के लिए, Firebase CLI 14.0.0 और इसके बाद के वर्शन में, आपको हर फ़ंक्शन डिप्लॉयमेंट के बाद डिप्लॉयमेंट आर्टफ़ैक्ट सेव करने वाली रिपॉज़िटरी के लिए, Artifact Registry डेटा मिटाने की नीति कॉन्फ़िगर करने की सुविधा मिलती है.
functions:artifacts:setpolicy
कमांड का इस्तेमाल करके, डेटा मिटाने की नीति को मैन्युअल तरीके से सेट अप या उसमें बदलाव किया जा सकता है:
firebase functions:artifacts:setpolicy
डिफ़ॉल्ट रूप से, यह कमांड Artifact Registry को एक दिन से ज़्यादा पुरानी कंटेनर इमेज को अपने-आप मिटाने के लिए कॉन्फ़िगर करती है. इससे स्टोरेज की लागत को कम करने और हाल की बिल्ड की संभावित जांच करने के बीच सही संतुलन बनाए रखने में मदद मिलती है.
--days
विकल्प का इस्तेमाल करके, डेटा के रखरखाव की अवधि को पसंद के मुताबिक बनाया जा सकता है:
firebase functions:artifacts:setpolicy --days 7 # Delete images older than 7 days
अगर आपने फ़ंक्शन को एक से ज़्यादा क्षेत्रों में डिप्लॉय किया है, तो --location
विकल्प का इस्तेमाल करके, किसी खास जगह के लिए डेटा मिटाने की नीति सेट अप की जा सकती है:
$ firebase functions:artifacts:setpolicy --location europe-west1
आर्टफ़ैक्ट को हटाने की सुविधा से ऑप्ट आउट करना
अगर आपको इमेज को मैन्युअल तरीके से साफ़ करना है या आपको कोई भी इमेज नहीं मिटानी है, तो इमेज साफ़ करने से जुड़ी नीतियों से पूरी तरह ऑप्ट आउट किया जा सकता है:
$ firebase functions:artifacts:setpolicy --none
इस कमांड से, Firebase CLI की सेट अप की गई मौजूदा क्लीनअप नीति हट जाती है. साथ ही, फ़ंक्शन डिप्लॉयमेंट के बाद Firebase को क्लीनअप नीति सेट अप करने से रोका जाता है.
फ़ंक्शन मिटाना
पहले से डिप्लॉय किए गए फ़ंक्शन को इन तरीकों से मिटाया जा सकता है:
functions:delete
के साथ Firebase सीएलआई में साफ़ तौर पर- Google Cloud कंसोल में साफ़ तौर पर बताया गया हो.
- डिप्लॉयमेंट से पहले, सोर्स से फ़ंक्शन हटाकर सीधे तौर पर.
मिटाने से जुड़ी सभी कार्रवाइयों में, प्रोडक्शन से फ़ंक्शन हटाने से पहले पुष्टि करने के लिए कहा जाता है.
Firebase CLI में फ़ंक्शन को मिटाने की सुविधा में कई तर्क और फ़ंक्शन ग्रुप इस्तेमाल किए जा सकते हैं. साथ ही, इससे किसी खास क्षेत्र में चल रहे फ़ंक्शन के बारे में जानकारी दी जा सकती है. इसके अलावा, पुष्टि करने के लिए दिखने वाले प्रॉम्प्ट को भी अनदेखा किया जा सकता है.
# Delete all functions that match the specified name in all regions. firebase functions:delete myFunction
# Delete a specified function running in a specific region. firebase functions:delete myFunction --region us-east-1
# Delete more than one function firebase functions:delete myFunction myOtherFunction
# Delete a specified functions group. firebase functions:delete groupA
# Bypass the confirmation prompt. firebase functions:delete myFunction --force
फ़ंक्शन को अपने-आप मिटाने की सुविधा की मदद से, firebase deploy
आपके सोर्स को पार्स करता है. साथ ही, प्रोडक्शन से उन सभी फ़ंक्शन को हटा देता है जिन्हें फ़ाइल से हटा दिया गया है.
किसी फ़ंक्शन का नाम, क्षेत्र या ट्रिगर बदलना
अगर आपको प्रोडक्शन ट्रैफ़िक को मैनेज करने वाले फ़ंक्शन के नाम बदलने हैं या उनके ट्रिगर या क्षेत्र बदलने हैं, तो बदलाव के दौरान इवेंट का डेटा न मिटाने के लिए, इस सेक्शन में दिया गया तरीका अपनाएं. यह तरीका अपनाने से पहले, पक्का करें कि आपका फ़ंक्शन आईडम्पोटेंट है. ऐसा इसलिए, क्योंकि बदलाव के दौरान आपके फ़ंक्शन का नया और पुराना, दोनों वर्शन एक साथ काम करेंगे.
किसी फ़ंक्शन का नाम बदलना
किसी फ़ंक्शन का नाम बदलने के लिए, अपने सोर्स में फ़ंक्शन का नया नाम वाला वर्शन बनाएं. इसके बाद, दो अलग-अलग डिप्लॉयमेंट कमांड चलाएं. पहले निर्देश से, नए नाम वाले फ़ंक्शन को डिप्लॉय किया जाता है. वहीं, दूसरे निर्देश से, पहले डिप्लॉय किए गए वर्शन को हटाया जाता है. उदाहरण के लिए, अगर आपको webhook
नाम के Node.js फ़ंक्शन को webhookNew
में बदलना है, तो कोड में इस तरह बदलाव करें:
// before
const functions = require('firebase-functions/v1');
exports.webhook = functions.https.onRequest((req, res) => {
res.send("Hello");
});
// after
const functions = require('firebase-functions/v1');
exports.webhookNew = functions.https.onRequest((req, res) => {
res.send("Hello");
});
इसके बाद, नए फ़ंक्शन को डिप्लॉय करने के लिए, ये कमांड चलाएं:
# Deploy new function called webhookNew firebase deploy --only functions:webhookNew # Wait until deployment is done; now both webhookNew and webhook are running # Delete webhook firebase functions:delete webhook
किसी फ़ंक्शन के लिए, देश या इलाके का नाम बदलना
अगर आपको प्रोडक्शन ट्रैफ़िक को मैनेज करने वाले फ़ंक्शन के लिए, तय की गई जगहों में बदलाव करना है, तो इवेंट के डेटा के नुकसान को रोका जा सकता है. इसके लिए, इन चरणों को क्रम से पूरा करें:
- फ़ंक्शन का नाम बदलें और अपनी पसंद के मुताबिक, उसके क्षेत्र या क्षेत्रों में बदलाव करें.
- नाम बदले गए फ़ंक्शन को डिप्लॉय करें. इससे, कुछ समय के लिए दोनों सेट के इलाकों में एक ही कोड चलेगा.
- पिछले फ़ंक्शन को मिटाओ.
उदाहरण के लिए, अगर आपके पास webhook
नाम का कोई फ़ंक्शन है, जो फ़िलहाल us-central1
के डिफ़ॉल्ट फ़ंक्शन वाले क्षेत्र में है और आपको इसे asia-northeast1
पर माइग्रेट करना है, तो आपको पहले अपने सोर्स कोड में बदलाव करना होगा. इसके लिए, फ़ंक्शन का नाम बदलें और क्षेत्र में बदलाव करें.
// before
const functions = require('firebase-functions/v1');
exports.webhook = functions
.https.onRequest((req, res) => {
res.send("Hello");
});
// after
const functions = require('firebase-functions/v1');
exports.webhookAsia = functions
.region('asia-northeast1')
.https.onRequest((req, res) => {
res.send("Hello");
});
इसके बाद, यह कमांड चलाकर डिप्लॉय करें:
firebase deploy --only functions:webhookAsia
अब दो एक जैसे फ़ंक्शन चल रहे हैं: webhook
, us-central1
में चल रहा है और webhookAsia
, asia-northeast1
में चल रहा है.
इसके बाद, webhook
मिटाएं:
firebase functions:delete webhook
अब सिर्फ़ एक फ़ंक्शन - webhookAsia
है, जो asia-northeast1
में चल रहा है.
फ़ंक्शन के ट्रिगर का टाइप बदलना
समय के साथ Cloud Functions for Firebase को डिप्लॉय करने के दौरान, आपको कई वजहों से किसी फ़ंक्शन के ट्रिगर टाइप को बदलने की ज़रूरत पड़ सकती है. उदाहरण के लिए, हो सकता है कि आपको एक तरह के Firebase Realtime Database या Cloud Firestore इवेंट से दूसरी तरह के इवेंट पर स्विच करना हो.
सिर्फ़ सोर्स कोड बदलकर और firebase deploy
को चलाकर, किसी फ़ंक्शन के इवेंट टाइप को नहीं बदला जा सकता. गड़बड़ियों से बचने के लिए, फ़ंक्शन के ट्रिगर टाइप को इस तरीके से बदलें:
- सोर्स कोड में बदलाव करके, ट्रिगर के मनमुताबिक टाइप वाला नया फ़ंक्शन शामिल करें.
- फ़ंक्शन को डिप्लॉय करें. इससे, कुछ समय के लिए पुराने और नए, दोनों फ़ंक्शन चलते हैं.
- Firebase CLI का इस्तेमाल करके, प्रोडक्शन से पुराने फ़ंक्शन को साफ़ तौर पर मिटाएं.
उदाहरण के लिए, अगर आपके पास objectChanged
नाम का कोई Node.js फ़ंक्शन है, जिसमें लेगसी onChange
इवेंट टाइप है और आपको इसे onFinalize
में बदलना है, तो पहले फ़ंक्शन का नाम बदलें और उसे onFinalize
इवेंट टाइप में बदलें.
// before
const functions = require('firebase-functions/v1');
exports.objectChanged = functions.storage.object().onChange((object) => {
return console.log('File name is: ', object.name);
});
// after
const functions = require('firebase-functions/v1');
exports.objectFinalized = functions.storage.object().onFinalize((object) => {
return console.log('File name is: ', object.name);
});
इसके बाद, पुराने फ़ंक्शन को मिटाने से पहले, नया फ़ंक्शन बनाने के लिए यहां दिए गए निर्देश चलाएं:
# Create new function objectFinalized firebase deploy --only functions:objectFinalized # Wait until deployment is done; now both objectChanged and objectFinalized are running # Delete objectChanged firebase functions:delete objectChanged
रनटाइम के विकल्प सेट करना
Cloud Functions for Firebase की मदद से, रनटाइम के विकल्प चुने जा सकते हैं. जैसे, Node.js रनटाइम वर्शन, हर फ़ंक्शन के लिए टाइम आउट, मेमोरी का बंटवारा, और फ़ंक्शन के कम से कम/ज़्यादा से ज़्यादा इंस्टेंस.
सबसे सही तरीके के तौर पर, इन विकल्पों (Node.js वर्शन को छोड़कर) को फ़ंक्शन कोड में कॉन्फ़िगरेशन ऑब्जेक्ट पर सेट किया जाना चाहिए. यह RuntimeOptions
ऑब्जेक्ट, आपके फ़ंक्शन के रनटाइम विकल्पों के लिए सोर्स ऑफ़ ट्रुथ है. साथ ही, यह किसी अन्य तरीके से सेट किए गए विकल्पों को बदल देगा. जैसे, Google Cloud Console या gcloud CLI के ज़रिए सेट किए गए विकल्प.
अगर आपके डेवलपमेंट वर्कफ़्लो में, Google Cloud Console या gcloud CLI के ज़रिए मैन्युअल तरीके से रनटाइम के विकल्प सेट किए जाते हैं और आपको हर डिप्लॉयमेंट पर इन वैल्यू को बदलने की ज़रूरत नहीं है, तो preserveExternalChanges
विकल्प को true
पर सेट करें.
इस विकल्प को true
पर सेट करने पर, Firebase आपके कोड में सेट किए गए रनटाइम विकल्पों को, फ़ंक्शन के मौजूदा समय में डिप्लॉय किए गए वर्शन की सेटिंग के साथ मर्ज कर देता है. ऐसा इस क्रम में किया जाता है:
- यह विकल्प, फ़ंक्शन के कोड में सेट किया जाता है: बाहरी बदलावों को खारिज करें.
- फ़ंक्शन कोड में विकल्प को
RESET_VALUE
पर सेट किया गया है: डिफ़ॉल्ट वैल्यू के साथ बाहरी बदलावों को बदलें. - फ़ंक्शन कोड में विकल्प सेट नहीं किया गया है, लेकिन फ़िलहाल डिप्लॉय किए गए फ़ंक्शन में सेट किया गया है: डिप्लॉय किए गए फ़ंक्शन में बताए गए विकल्प का इस्तेमाल करें.
ज़्यादातर स्थितियों में, preserveExternalChanges: true
विकल्प का इस्तेमाल करने का सुझाव नहीं दिया जाता. ऐसा इसलिए, क्योंकि अब आपका कोड, फ़ंक्शन के रनटाइम विकल्पों के लिए, भरोसेमंद सोर्स नहीं रहेगा. अगर आपने इसका इस्तेमाल किया है, तो Google Cloud Console देखें या gcloud CLI का इस्तेमाल करके, किसी फ़ंक्शन का पूरा कॉन्फ़िगरेशन देखें.
Node.js का वर्शन सेट करना
Cloud Functions के लिए Firebase SDK टूल की मदद से, Node.js रनटाइम को चुना जा सकता है. आपके पास किसी प्रोजेक्ट में सभी फ़ंक्शन को सिर्फ़ ऐसे रनटाइम एनवायरमेंट पर चलाने का विकल्प होता है जो Node.js के इन वर्शन के साथ काम करता हो:
- Node.js 20
- Node.js 18 (अब सेवा में नहीं है)
Node.js के इन वर्शन के लिए, सहायता जारी रखने से जुड़ी अहम जानकारी के लिए, सहायता का शेड्यूल देखें.
Node.js का वर्शन सेट करने के लिए:
शुरुआत के दौरान, functions/
डायरेक्ट्री में बनाई गई package.json
फ़ाइल के engines
फ़ील्ड में वर्शन सेट किया जा सकता है.
उदाहरण के लिए, सिर्फ़ वर्शन 20 का इस्तेमाल करने के लिए, package.json
में इस लाइन में बदलाव करें:
"engines": {"node": "20"}
अगर Yarn पैकेज मैनेजर का इस्तेमाल किया जा रहा है या engines
फ़ील्ड के लिए आपकी कुछ खास ज़रूरतें हैं, तो firebase.json
में जाकर, Cloud Functions के लिए Firebase SDK टूल का रनटाइम सेट किया जा सकता है:
{
"functions": {
"runtime": "nodejs20"
}
}
सीएलआई, package.json
में अलग से सेट की गई किसी भी वैल्यू या रेंज के बजाय, firebase.json
में सेट की गई वैल्यू का इस्तेमाल करता है.
Node.js रनटाइम को अपग्रेड करना
Node.js रनटाइम को अपग्रेड करने के लिए:
- पक्का करें कि आपका प्रोजेक्ट ब्लेज़ प्राइसिंग प्लान पर हो.
- पक्का करें कि Firebase CLI v11.18.0 या इसके बाद का वर्शन इस्तेमाल किया जा रहा हो.
- शुरू करने के दौरान, अपनी
functions/
डायरेक्ट्री में बनाई गईpackage.json
फ़ाइल मेंengines
वैल्यू बदलें. उदाहरण के लिए, अगर आपको वर्शन 16 से वर्शन 18 पर अपग्रेड करना है, तो एंट्री ऐसी दिखनी चाहिए:"engines": {"node": "18"}
- अगर चाहें, तो Firebase Local Emulator Suite का इस्तेमाल करके, अपने बदलावों की जांच करें.
- सभी फ़ंक्शन फिर से डिप्लॉय करें.
स्केलिंग के तरीके को कंट्रोल करना
डिफ़ॉल्ट रूप से, Cloud Functions for Firebase चालू इंस्टेंस की संख्या को आने वाले अनुरोधों की संख्या के आधार पर बढ़ाता है. ट्रैफ़िक कम होने पर, यह संख्या शून्य तक कम हो सकती है. हालांकि, अगर आपके ऐप्लिकेशन को कम लेटेन्सी की ज़रूरत है और आपको कोल्ड स्टार्ट की संख्या को सीमित करना है, तो इस डिफ़ॉल्ट व्यवहार को बदला जा सकता है. इसके लिए, कंटेनर इंस्टेंस की कम से कम संख्या तय करें, ताकि उन्हें वॉर्म रखा जा सके और वे अनुरोधों को पूरा करने के लिए तैयार रहें.
इसी तरह, आने वाले अनुरोधों के जवाब में इंस्टेंस की संख्या को बढ़ाने की सीमा तय की जा सकती है. इस सेटिंग का इस्तेमाल, अपने खर्च को कंट्रोल करने के लिए किया जा सकता है. इसके अलावा, इसका इस्तेमाल डेटाबेस जैसी बैकिंग सेवा से कनेक्शन की संख्या को सीमित करने के लिए भी किया जा सकता है.
कोल्ड स्टार्ट की संख्या कम करना
सोर्स कोड में किसी फ़ंक्शन के लिए कम से कम इंस्टेंस सेट करने के लिए, runWith
तरीके का इस्तेमाल करें. यह तरीका, RuntimeOptions
इंटरफ़ेस के मुताबिक JSON ऑब्जेक्ट स्वीकार करता है. यह इंटरफ़ेस, minInstances
के लिए वैल्यू तय करता है. उदाहरण के लिए,
यह फ़ंक्शन, कम से कम पांच इंस्टेंस को चालू रखता है:
exports.getAutocompleteResponse = functions
.runWith({
// Keep 5 instances warm for this latency-critical function
minInstances: 5,
})
.https.onCall((data, context) => {
// Autocomplete a user's search term
});
minInstances
के लिए वैल्यू सेट करते समय, इन बातों का ध्यान रखें:
- अगर Cloud Functions for Firebase, आपके ऐप्लिकेशन को
minInstances
सेटिंग से ज़्यादा स्केल करता है, तो आपको उस थ्रेशोल्ड से ऊपर के हर इंस्टेंस के लिए कोल्ड स्टार्ट का सामना करना पड़ेगा. - कोल्ड स्टार्ट का सबसे ज़्यादा असर, ट्रैफ़िक में अचानक बढ़ोतरी वाले ऐप्लिकेशन पर पड़ता है. अगर आपके ऐप्लिकेशन में ट्रैफ़िक में अचानक बढ़ोतरी होती है और आपने
minInstances
की वैल्यू इतनी ज़्यादा सेट की है कि ट्रैफ़िक में हर बार बढ़ोतरी होने पर कोल्ड स्टार्ट कम हो जाते हैं, तो आपको लेटेन्सी में काफ़ी कमी दिखेगी. जिन ऐप्लिकेशन पर लगातार ट्रैफ़िक आता है उनकी परफ़ॉर्मेंस पर कोल्ड स्टार्ट का ज़्यादा असर नहीं पड़ता. प्रोडक्शन एनवायरमेंट के लिए, कम से कम इंस्टेंस सेट करना सही हो सकता है. हालांकि, टेस्टिंग एनवायरमेंट में ऐसा करने से बचना चाहिए. अपने टेस्ट प्रोजेक्ट में स्केल-टू-ज़ीरो की सुविधा चालू करने के लिए, लेकिन प्रोडक्शन प्रोजेक्ट में कोल्ड स्टार्ट को कम करने के लिए,
FIREBASE_CONFIG
एनवायरमेंट वैरिएबल के आधार परminInstances
सेट किया जा सकता है:// Get Firebase project id from `FIREBASE_CONFIG` environment variable const envProjectId = JSON.parse(process.env.FIREBASE_CONFIG).projectId; exports.renderProfilePage = functions .runWith({ // Keep 5 instances warm for this latency-critical function // in production only. Default to 0 for test projects. minInstances: envProjectId === "my-production-project" ? 5 : 0, }) .https.onRequest((req, res) => { // render some html });
किसी फ़ंक्शन के लिए ज़्यादा से ज़्यादा इंस्टेंस की संख्या को सीमित करना
फ़ंक्शन के सोर्स कोड में ज़्यादा से ज़्यादा इंस्टेंस सेट करने के लिए, runWith
तरीके का इस्तेमाल करें. यह तरीका, RuntimeOptions
इंटरफ़ेस के मुताबिक JSON ऑब्जेक्ट स्वीकार करता है. यह maxInstances
के लिए वैल्यू तय करता है. उदाहरण के लिए, यह फ़ंक्शन किसी काल्पनिक लेगसी डेटाबेस पर ज़्यादा लोड न पड़े, इसके लिए 100 इंस्टेंस की सीमा तय करता है:
exports.mirrorOrdersToLegacyDatabase = functions
.runWith({
// Legacy database only supports 100 simultaneous connections
maxInstances: 100,
})
.firestore.document("orders/{orderId}")
.onWrite((change, context) => {
// Connect to legacy database
});
अगर किसी एचटीटीपी फ़ंक्शन को maxInstances
सीमा तक बढ़ाया जाता है, तो नए अनुरोधों को 30 सेकंड के लिए लाइन में लगा दिया जाता है. इसके बाद, अगर कोई इंस्टेंस उपलब्ध नहीं होता है, तो उन्हें 429 Too Many Requests
रिस्पॉन्स कोड के साथ अस्वीकार कर दिया जाता है.
ज़्यादा से ज़्यादा इंस्टेंस इस्तेमाल करने की सेटिंग के सबसे सही तरीकों के बारे में ज़्यादा जानने के लिए, maxInstances
इस्तेमाल करने के सबसे सही तरीके देखें.
टाइम आउट और मेमोरी का बंटवारा सेट करना
कुछ मामलों में, आपके फ़ंक्शन के लिए टाइम आउट की लंबी वैल्यू या ज़्यादा मेमोरी की ज़रूरत हो सकती है. इन वैल्यू को Google Cloud Console या फ़ंक्शन के सोर्स कोड (सिर्फ़ Firebase) में सेट किया जा सकता है.
फ़ंक्शन के सोर्स कोड में मेमोरी का बंटवारा और टाइम आउट सेट करने के लिए, Cloud Functions 2.0.0 के लिए Firebase SDK में जोड़े गए runWith
पैरामीटर का इस्तेमाल करें. यह रनटाइम विकल्प, RuntimeOptions
इंटरफ़ेस के मुताबिक JSON ऑब्जेक्ट स्वीकार करता है. यह timeoutSeconds
और memory
के लिए वैल्यू तय करता है.
उदाहरण के लिए, यह स्टोरेज फ़ंक्शन 1 जीबी मेमोरी का इस्तेमाल करता है और 300 सेकंड के बाद टाइम आउट हो जाता है:
exports.convertLargeFile = functions
.runWith({
// Ensure the function has enough memory and time
// to process large files
timeoutSeconds: 300,
memory: "1GB",
})
.storage.object()
.onFinalize((object) => {
// Do some complicated things that take a lot of memory and time
});
timeoutSeconds
की ज़्यादा से ज़्यादा वैल्यू 540
या नौ मिनट है.
किसी फ़ंक्शन को दी गई मेमोरी की मात्रा, उस फ़ंक्शन के लिए तय किए गए सीपीयू (CPU) के हिसाब से होती है. memory
के लिए मान्य वैल्यू की इस सूची में इसके बारे में पूरी जानकारी दी गई है:
128MB
— 200 मेगाहर्ट्ज़256MB
— 400 मेगाहर्ट्ज़512MB
— 800 मेगाहर्ट्ज़1GB
— 1.4 गीगाहर्ट्ज़2GB
— 2.4 गीगाहर्ट्ज़4GB
— 4.8 गीगाहर्ट्ज़8GB
— 4.8 गीगाहर्ट्ज़
Google Cloud कंसोल में मेमोरी का बंटवारा और टाइम आउट सेट करने के लिए:
- Google Google Cloud console में, बाईं ओर मौजूद मेन्यू से Cloud Functions चुनें.
- फ़ंक्शन की सूची में, उसके नाम पर क्लिक करके कोई फ़ंक्शन चुनें.
- सबसे ऊपर मौजूद मेन्यू में, बदलाव करें आइकॉन पर क्लिक करें.
- मेमोरी असाइन की गई लेबल वाले ड्रॉप-डाउन मेन्यू से, मेमोरी असाइन करने का कोई विकल्प चुनें.
- ऐडवांस विकल्प दिखाने के लिए, ज़्यादा पर क्लिक करें. इसके बाद, टाइम आउट टेक्स्ट बॉक्स में सेकंड की संख्या डालें.
- फ़ंक्शन को अपडेट करने के लिए, सेव करें पर क्लिक करें.