फ़ंक्शन मैनेज करें

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 आपके सोर्स को पार्स करता है. साथ ही, प्रोडक्शन से उन सभी फ़ंक्शन को हटा देता है जिन्हें फ़ाइल से हटा दिया गया है.

किसी फ़ंक्शन का नाम, क्षेत्र या ट्रिगर बदलना

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

किसी फ़ंक्शन का नाम बदलना

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

// before
const {onRequest}  = require('firebase-functions/v2/https');

exports.webhook = onRequest((req, res) => {
    res.send("Hello");
});

// after
const {onRequest}  = require('firebase-functions/v2/https');

exports.webhookNew = onRequest((req, res) => {
    res.send("Hello");
});

# before
from firebase_functions import https_fn

@https_fn.on_request()
def webhook(req: https_fn.Request) -> https_fn.Response:
    return https_fn.Response("Hello world!")

# after
from firebase_functions import https_fn

@https_fn.on_request()
def webhook_new(req: https_fn.Request) -> https_fn.Response:
    return https_fn.Response("Hello world!")

इसके बाद, नए फ़ंक्शन को डिप्लॉय करने के लिए, ये कमांड चलाएं:

# Deploy new function
firebase deploy --only functions:webhookNew

# Wait until deployment is done; now both functions are running

# Delete webhook
firebase functions:delete webhook

किसी फ़ंक्शन के लिए, देश या इलाके का नाम बदलना

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

1. फ़ंक्शन का नाम बदलें और अपनी पसंद के मुताबिक, उसके क्षेत्र या क्षेत्रों में बदलाव करें.
2. नाम बदले गए फ़ंक्शन को डिप्लॉय करें. इससे, कुछ समय के लिए दोनों सेट के इलाकों में एक ही कोड चलेगा.
3. पिछले फ़ंक्शन को मिटाओ.

उदाहरण के लिए, अगर आपके पास Cloud Firestore-ट्रिगर किया गया कोई फ़ंक्शन है, जो फ़िलहाल us-central1 के डिफ़ॉल्ट फ़ंक्शन वाले क्षेत्र में है और आपको उसे asia-northeast1 पर माइग्रेट करना है, तो आपको सबसे पहले अपने सोर्स कोड में बदलाव करना होगा. इसके लिए, फ़ंक्शन का नाम बदलें और क्षेत्र में बदलाव करें.

// before
exports.firestoreTrigger = onDocumentCreated(
  "my-collection/{docId}",
  (event) => {},
);

// after
exports.firestoreTriggerAsia = onDocumentCreated(
  {
    document: "my-collection/{docId}",
    region: "asia-northeast1",
  },
  (event) => {},
);

# Before
@firestore_fn.on_document_created("my-collection/{docId}")
def firestore_trigger(event):
    pass

# After
@firestore_fn.on_document_created("my-collection/{docId}",
                                  region="asia-northeast1")
def firestore_trigger_asia(event):
    pass

इसके बाद, यह कमांड चलाकर डिप्लॉय करें:

firebase deploy --only functions:firestoreTriggerAsia

अब दो एक जैसे फ़ंक्शन चल रहे हैं: firestoreTrigger, us-central1 में चल रहा है और firestoreTriggerAsia, asia-northeast1 में चल रहा है.

इसके बाद, firestoreTrigger मिटाएं:

firebase functions:delete firestoreTrigger

अब सिर्फ़ एक फ़ंक्शन - firestoreTriggerAsia है, जो asia-northeast1 में चल रहा है.

फ़ंक्शन के ट्रिगर का टाइप बदलना

समय के साथ Cloud Functions for Firebase को डिप्लॉय करने के दौरान, आपको कई वजहों से किसी फ़ंक्शन के ट्रिगर टाइप को बदलने की ज़रूरत पड़ सकती है. उदाहरण के लिए, हो सकता है कि आपको एक तरह के Firebase Realtime Database या Cloud Firestore इवेंट से दूसरी तरह के इवेंट पर स्विच करना हो.

सिर्फ़ सोर्स कोड बदलकर और firebase deploy को चलाकर, किसी फ़ंक्शन के इवेंट टाइप को नहीं बदला जा सकता. गड़बड़ियों से बचने के लिए, फ़ंक्शन के ट्रिगर टाइप को इस तरीके से बदलें:

1. सोर्स कोड में बदलाव करके, ट्रिगर के मनमुताबिक टाइप वाला नया फ़ंक्शन शामिल करें.
2. फ़ंक्शन को डिप्लॉय करें. इससे, कुछ समय के लिए पुराने और नए, दोनों फ़ंक्शन चलते हैं.
3. Firebase CLI का इस्तेमाल करके, प्रोडक्शन से पुराने फ़ंक्शन को साफ़ तौर पर मिटाएं.

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

// before
const {onObjectDeleted} = require("firebase-functions/v2/storage");

exports.objectDeleted = onObjectDeleted((event) => {
    // ...
});

// after
const {onObjectArchived} = require("firebase-functions/v2/storage");

exports.objectArchived = onObjectArchived((event) => {
    // ...
});

# before
from firebase_functions import storage_fn

@storage_fn.on_object_deleted()
def object_deleted(event):
  # ...

# after 
from firebase_functions import storage_fn

@storage_fn.on_object_archived()
def object_archived(event):
  # ...

इसके बाद, पुराने फ़ंक्शन को मिटाने से पहले, नया फ़ंक्शन बनाने के लिए यहां दिए गए निर्देश चलाएं:

# Create new function objectArchived
firebase deploy --only functions:objectArchived

# Wait until deployment is done; now both objectDeleted and objectArchived are running

# Delete objectDeleted
firebase functions:delete objectDeleted

रनटाइम के विकल्प सेट करना

Cloud Functions for Firebase की मदद से, रनटाइम के विकल्प चुने जा सकते हैं. जैसे, Node.js रनटाइम वर्शन, हर फ़ंक्शन के लिए टाइम आउट, मेमोरी का बंटवारा, और फ़ंक्शन के कम से कम/ज़्यादा से ज़्यादा इंस्टेंस.

सबसे सही तरीके के तौर पर, इन विकल्पों (Node.js वर्शन को छोड़कर) को फ़ंक्शन कोड में कॉन्फ़िगरेशन ऑब्जेक्ट पर सेट किया जाना चाहिए. यह RuntimeOptions ऑब्जेक्ट, आपके फ़ंक्शन के रनटाइम विकल्पों के लिए सोर्स ऑफ़ ट्रुथ है. साथ ही, यह किसी अन्य तरीके से सेट किए गए विकल्पों को बदल देगा. जैसे, Google Cloud Console या gcloud CLI के ज़रिए सेट किए गए विकल्प.

अगर आपके डेवलपमेंट वर्कफ़्लो में, Google Cloud Console या gcloud CLI के ज़रिए मैन्युअल तरीके से रनटाइम के विकल्प सेट किए जाते हैं और आपको हर डिप्लॉयमेंट पर इन वैल्यू को बदलने की ज़रूरत नहीं है, तो preserveExternalChanges विकल्प को true पर सेट करें. इस विकल्प को true पर सेट करने पर, Firebase आपके कोड में सेट किए गए रनटाइम विकल्पों को, फ़ंक्शन के मौजूदा समय में डिप्लॉय किए गए वर्शन की सेटिंग के साथ मर्ज कर देता है. ऐसा इस क्रम में किया जाता है:

1. यह विकल्प, फ़ंक्शन के कोड में सेट किया जाता है: बाहरी बदलावों को खारिज करें.
2. फ़ंक्शन कोड में विकल्प को RESET_VALUE पर सेट किया गया है: डिफ़ॉल्ट वैल्यू के साथ बाहरी बदलावों को बदलें.
3. फ़ंक्शन कोड में विकल्प सेट नहीं किया गया है, लेकिन फ़िलहाल डिप्लॉय किए गए फ़ंक्शन में सेट किया गया है: डिप्लॉय किए गए फ़ंक्शन में बताए गए विकल्प का इस्तेमाल करें.

ज़्यादातर स्थितियों में, preserveExternalChanges: true विकल्प का इस्तेमाल करने का सुझाव नहीं दिया जाता. ऐसा इसलिए, क्योंकि अब आपका कोड, फ़ंक्शन के रनटाइम विकल्पों के लिए, भरोसेमंद सोर्स नहीं रहेगा. अगर आपने इसका इस्तेमाल किया है, तो Google Cloud Console देखें या gcloud CLI का इस्तेमाल करके, किसी फ़ंक्शन का पूरा कॉन्फ़िगरेशन देखें.

Node.js का वर्शन सेट करना

Cloud Functions के लिए Firebase SDK टूल की मदद से, Node.js रनटाइम को चुना जा सकता है. आपके पास किसी प्रोजेक्ट में सभी फ़ंक्शन को सिर्फ़ ऐसे रनटाइम एनवायरमेंट पर चलाने का विकल्प होता है जो Node.js के इन वर्शन के साथ काम करता हो:

• Node.js 22
• Node.js 20
• Node.js 18 (अब सेवा में नहीं है)

Node.js के वर्शन 14 और 16 को 2025 की शुरुआत में बंद कर दिया गया था. इन वर्शन के साथ डिप्लॉयमेंट की सुविधा बंद है. 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" // or nodejs22
    }
  }

सीएलआई, package.json में अलग से सेट की गई किसी भी वैल्यू या रेंज के बजाय, firebase.json में सेट की गई वैल्यू का इस्तेमाल करता है.

Node.js रनटाइम को अपग्रेड करना

Node.js रनटाइम को अपग्रेड करने के लिए:

1. पक्का करें कि आपका प्रोजेक्ट ब्लेज़ प्राइसिंग प्लान पर हो.
2. पक्का करें कि Firebase CLI v11.18.0 या इसके बाद का वर्शन इस्तेमाल किया जा रहा हो.
3. शुरू करने के दौरान, अपनी functions/ डायरेक्ट्री में बनाई गई package.json फ़ाइल में engines वैल्यू बदलें. उदाहरण के लिए, अगर आपको वर्शन 18 से वर्शन 20 पर अपग्रेड करना है, तो एंट्री ऐसी दिखनी चाहिए: "engines": {"node": "20"}
4. अगर चाहें, तो Firebase Local Emulator Suite का इस्तेमाल करके, अपने बदलावों की जांच करें.
5. सभी फ़ंक्शन फिर से डिप्लॉय करें.

Python का वर्शन सेट करना

Firebase SDK टूल के Cloud Functions वर्शन 12.0.0 और इसके बाद के वर्शन में, Python रनटाइम को चुनने की सुविधा मिलती है. firebase.json में रनटाइम वर्शन को इस तरह सेट करें:

  {
    "functions": {
      "runtime": "python310" // or python311
    }
  }

स्केलिंग के तरीके को कंट्रोल करना

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

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

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

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

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

एक साथ कई अनुरोधों को अनुमति दें

Cloud Functions for Firebase (पहली जनरेशन) में, हर इंस्टेंस एक बार में एक अनुरोध को प्रोसेस कर सकता था. इसलिए, स्केलिंग के व्यवहार को सिर्फ़ कम से कम और ज़्यादा से ज़्यादा इंस्टेंस की सेटिंग के साथ सेट किया गया था. Cloud Functions for Firebase (दूसरी जनरेशन) में, इंस्टेंस की संख्या को कंट्रोल करने के साथ-साथ, concurrency विकल्प का इस्तेमाल करके यह भी कंट्रोल किया जा सकता है कि हर इंस्टेंस एक ही समय में कितने अनुरोध पूरे कर सकता है. कॉन्करेंसी के लिए डिफ़ॉल्ट वैल्यू 80 होती है. हालांकि, इसे 1 से 1000 के बीच के किसी भी पूर्णांक पर सेट किया जा सकता है.

ज़्यादा कॉन्करेंसी सेटिंग वाले फ़ंक्शन, कोल्ड स्टार्ट किए बिना ट्रैफ़िक में अचानक होने वाली बढ़ोतरी को झेल सकते हैं. ऐसा इसलिए, क्योंकि हर इंस्टेंस में कुछ हेडरूम होता है. अगर किसी इंस्टेंस को एक साथ 50 अनुरोधों को प्रोसेस करने के लिए कॉन्फ़िगर किया गया है, लेकिन फ़िलहाल वह सिर्फ़ 25 अनुरोधों को प्रोसेस कर रहा है, तो वह 25 और अनुरोधों को प्रोसेस कर सकता है. इसके लिए, उसे नए इंस्टेंस को कोल्ड स्टार्ट करने की ज़रूरत नहीं होगी. इसके उलट, अगर एक साथ कई अनुरोध करने की सेटिंग सिर्फ़ 1 पर सेट है, तो अनुरोधों में अचानक हुई इस बढ़ोतरी की वजह से 25 कोल्ड स्टार्ट हो सकते हैं.

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

Cloud Functions for Firebase (दूसरी जनरेशन) में एक साथ कई अनुरोध प्रोसेस करने की सेटिंग के साथ एक्सपेरिमेंट करते समय, इन बातों का ध्यान रखें:

• एक साथ कई अनुरोध प्रोसेस करने की सेटिंग को ज़्यादा पर सेट करने पर, बेहतर परफ़ॉर्मेंस के लिए ज़्यादा सीपीयू और रैम की ज़रूरत पड़ सकती है. हालांकि, ऐसा तब तक होता है, जब तक कि यह सेटिंग एक व्यावहारिक सीमा तक नहीं पहुंच जाती. उदाहरण के लिए, इमेज या वीडियो को प्रोसेस करने वाले किसी फ़ंक्शन के पास, एक साथ 1,000 अनुरोधों को हैंडल करने के लिए ज़रूरी संसाधन नहीं हो सकते. भले ही, उसकी सीपीयू और रैम सेटिंग को ज़्यादा से ज़्यादा पर सेट किया गया हो.
• Cloud Functions for Firebase (दूसरी जनरेशन) में Cloud Run की सुविधा है. इसलिए, एक साथ कई काम करने की सुविधा को ऑप्टिमाइज़ करने के लिए, Google Cloud से जुड़ी गाइड भी देखी जा सकती है.
• प्रोडक्शन में एक से ज़्यादा मुद्राओं का इस्तेमाल करने से पहले, टेस्ट एनवायरमेंट में एक से ज़्यादा मुद्राओं का इस्तेमाल करके अच्छी तरह से जांच कर लें.

कम से कम इंस्टेंस को चालू रखें

सोर्स कोड में किसी फ़ंक्शन के लिए, कम से कम इंस्टेंस की संख्या सेट की जा सकती है. उदाहरण के लिए, यह फ़ंक्शन कम से कम पांच इंस्टेंस को चालू रखता है:

const { onCall } = require("firebase-functions/v2/https");

exports.getAutocompleteResponse = onCall(
  {
    // Keep 5 instances warm for this latency-critical function
    minInstances: 5,
  },
  (event) => {
    // Autocomplete user’s search term
  }
);

@https_fn.on_call(min_instances=5)
def get_autocomplete_response(event: https_fn.CallableRequest) -> https_fn.Response:

कम से कम इंस्टेंस की वैल्यू सेट करते समय, इन बातों का ध्यान रखें:

• अगर Cloud Functions for Firebase आपके ऐप्लिकेशन को आपकी सेटिंग से ज़्यादा स्केल करता है, तो आपको उस थ्रेशोल्ड से ऊपर के हर इंस्टेंस के लिए कोल्ड स्टार्ट का सामना करना पड़ेगा.
• कोल्ड स्टार्ट का सबसे ज़्यादा असर, ट्रैफ़िक में अचानक बढ़ोतरी वाले ऐप्लिकेशन पर पड़ता है. अगर आपके ऐप्लिकेशन में ट्रैफ़िक में अचानक बढ़ोतरी होती है और आपने वैल्यू को इतना ज़्यादा सेट किया है कि ट्रैफ़िक में हर बार बढ़ोतरी होने पर कोल्ड स्टार्ट कम हो जाते हैं, तो आपको लेटेन्सी में काफ़ी कमी दिखेगी. जिन ऐप्लिकेशन पर लगातार ट्रैफ़िक आता है उनकी परफ़ॉर्मेंस पर, कोल्ड स्टार्ट का ज़्यादा असर नहीं पड़ता.

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

  Node.js

  const functions = require('firebase-functions/v1');
  const { defineInt, defineString } = require('firebase-functions/params');
  
  // Define some parameters
  const minInstancesConfig = defineInt('HELLO_WORLD_MININSTANCES');
  const welcomeMessage = defineString('WELCOME_MESSAGE');
  
  // To use configured parameters inside the config for a function, provide them 
  // directly. To use them at runtime, call .value() on them.
  export const helloWorld = functions.runWith({ minInstances: minInstancesConfig}).https.onRequest(
    (req, res) => {
      res.send(`${welcomeMessage.value()}! I am a function.`);
    }
  );
  

  Python

  MIN_INSTANCES = params.IntParam("HELLO_WORLD_MININSTANCES")
  WELCOME_MESSAGE = params.StringParam("WELCOME_MESSAGE")
  
  @https_fn.on_request(min_instances=MIN_INSTANCES.value())
  def get_autocomplete_response(event: https_fn.Request) -> https_fn.Response:
      return https_fn.Response(f"{WELCOME_MESSAGE.value()} I'm a function.")
  

किसी फ़ंक्शन के लिए ज़्यादा से ज़्यादा इंस्टेंस की संख्या को सीमित करना

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

const { onMessagePublished } = require("firebase-functions/v2/pubsub");

exports.mirrorevents = onMessagePublished(
  { topic: "topic-name", maxInstances: 100 },
  (event) => {
    // Connect to legacy database
  }
);

@pubsub_fn.on_message_published(topic="topic-name", max_instances=100)
def mirrorevents(event: pubsub_fn.CloudEvent):
#  Connect to legacy database

अगर किसी एचटीटीपी फ़ंक्शन को इंस्टेंस की ज़्यादा से ज़्यादा सीमा तक बढ़ाया जाता है, तो नए अनुरोधों को 30 सेकंड के लिए कतार में रखा जाता है. इसके बाद, अगर कोई इंस्टेंस उपलब्ध नहीं होता है, तो उन्हें 429 Too Many Requests के रिस्पॉन्स कोड के साथ अस्वीकार कर दिया जाता है.

ज़्यादा से ज़्यादा इंस्टेंस की सेटिंग इस्तेमाल करने के सबसे सही तरीकों के बारे में ज़्यादा जानने के लिए, ज़्यादा से ज़्यादा इंस्टेंस सेट करने के सबसे सही तरीके देखें.

टाइम आउट और मेमोरी का बंटवारा सेट करना

कुछ मामलों में, आपके फ़ंक्शन के लिए टाइम आउट की लंबी वैल्यू या ज़्यादा मेमोरी की ज़रूरत हो सकती है. इन वैल्यू को Google Cloud कंसोल या फ़ंक्शन के सोर्स कोड (सिर्फ़ Firebase) में सेट किया जा सकता है.

फ़ंक्शन के सोर्स कोड में मेमोरी असाइन करने और टाइम आउट सेट करने के लिए, मेमोरी और टाइम आउट के लिए ग्लोबल विकल्पों का इस्तेमाल करें. इससे, फ़ंक्शन चलाने वाली वर्चुअल मशीन को अपनी पसंद के मुताबिक बनाया जा सकता है. उदाहरण के लिए, यह Cloud Storage फ़ंक्शन 1GiB मेमोरी का इस्तेमाल करता है और 300 सेकंड के बाद टाइम आउट हो जाता है:

exports.convertLargeFile = onObjectFinalized({
  timeoutSeconds: 300,
  memory: "1GiB",
}, (event) => {
  // Do some complicated things that take a lot of memory and time
});

@storage_fn.on_object_finalized(timeout_sec=300, memory=options.MemoryOption.GB_1)
def convert_large_file(event: storage_fn.CloudEvent):
# Do some complicated things that take a lot of memory and time.

टाइम आउट के लिए ज़्यादा से ज़्यादा वैल्यू 540 या नौ मिनट हो सकती है.

Google Cloud कंसोल में मेमोरी का बंटवारा और टाइम आउट सेट करने के लिए:

1. Google Cloud कंसोल में, बाईं ओर मौजूद मेन्यू से Cloud Functions for Firebase चुनें.
2. फ़ंक्शन की सूची में, उसके नाम पर क्लिक करके कोई फ़ंक्शन चुनें.
3. सबसे ऊपर मौजूद मेन्यू में, बदलाव करें आइकॉन पर क्लिक करें.
4. मेमोरी असाइन की गई लेबल वाले ड्रॉप-डाउन मेन्यू से, मेमोरी असाइन करने का कोई विकल्प चुनें.
5. ऐडवांस विकल्प दिखाने के लिए, ज़्यादा पर क्लिक करें. इसके बाद, टाइम आउट टेक्स्ट बॉक्स में सेकंड की संख्या डालें.
6. फ़ंक्शन को अपडेट करने के लिए, सेव करें पर क्लिक करें.

सीपीयू की डिफ़ॉल्ट सेटिंग बदलना

ज़्यादा से ज़्यादा 2 जीबी मेमोरी मिलती है. Cloud Functions for Firebase (दूसरी जनरेशन) में हर फ़ंक्शन के लिए डिफ़ॉल्ट रूप से एक सीपीयू मिलता है. इसके बाद, 4 और 8 जीबी के लिए दो सीपीयू मिलते हैं. ध्यान दें कि यह पहली जनरेशन के डिफ़ॉल्ट व्यवहार से काफ़ी अलग है. इससे कम मेमोरी वाली फ़ंक्शन के लिए लागत थोड़ी ज़्यादा हो सकती है. इसके बारे में यहां दी गई टेबल में बताया गया है:

अगर आपको दूसरी जनरेशन के फ़ंक्शन के लिए, पहली जनरेशन का बिहेवियर चाहिए, तो पहली जनरेशन के डिफ़ॉल्ट सेटिंग को ग्लोबल विकल्प के तौर पर सेट करें:

// Turn off Firebase defaults
setGlobalOptions({ cpu: 'gcf_gen1' });

# Use 1st gen behavior
set_global_options(cpu="gcf_gen1")

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

// Boost CPU in a function:
export const analyzeImage = onObjectFinalized({ cpu: 2 }, (event) => {
  // computer vision goes here
});

# Boost CPU in a function:
@storage_fn.on_object_finalized(cpu=2)
def analyze_image(event: storage_fn.CloudEvent):
# computer vision goes here