इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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

फ़ंक्शन डिप्लॉय करना

फ़ंक्शन डिप्लॉय करने के लिए, यह Firebase सीएलआई कमांड चलाएं:

firebase deploy --only functions

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

firebase deploy --only functions:addMessage,functions:makeUppercase

बड़ी संख्या में फ़ंक्शन डिप्लॉय करने पर, हो सकता है कि आप स्टैंडर्ड कोटा से ज़्यादा फ़ंक्शन डिप्लॉय कर दें. ऐसा होने पर, आपको एचटीटीपी 429 या 500 गड़बड़ी के मैसेज मिल सकते हैं. इस समस्या को हल करने के लिए, फ़ंक्शन को 10 या उससे कम के ग्रुप में डिप्लॉय करें.

उपलब्ध निर्देशों की पूरी सूची के लिए, Firebase सीएलआई रेफ़रंस देखें.

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

फ़ंक्शन मिटाना

पहले से डिप्लॉय किए गए फ़ंक्शन को इन तरीकों से मिटाया जा सकता है:

functions:delete के साथ Firebase सीएलआई में साफ़ तौर पर
Google Cloud कंसोल में साफ़ तौर पर.
डिप्लॉयमेंट से पहले, सोर्स से फ़ंक्शन को हटाकर अनजाने में.

डेटा मिटाने की सभी कार्रवाइयां, फ़ंक्शन को प्रोडक्शन से हटाने से पहले आपको पुष्टि करने के लिए कहती हैं.

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

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

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

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

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

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

Node.js

// 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");
});

Python

# 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

फ़ंक्शन का इलाका या इलाका बदलना

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

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

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

Node.js

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

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

अपडेट किए गए कोड में, क्षेत्र के साथ-साथ सही इवेंट फ़िल्टर (इस मामले में document) भी बताया जाना चाहिए. ज़्यादा जानकारी के लिए, Cloud Functions की जगह की जानकारी देखें.

Python

# 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 में चल रहा है और asia-northeast1 में firestoreTriggerAsia चल रहा है.

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

firebase functions:delete firestoreTrigger

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

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

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

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

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

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

Node.js

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

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

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

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

Python

# 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 कंसोल या gcloud CLI) से सेट किए गए विकल्पों को बदल देगा.

अगर आपके डेवलपमेंट वर्कफ़्लो में Google Cloud Console या gcloud सीएलआई के ज़रिए मैन्युअल तरीके से रनटाइम के विकल्प सेट करना शामिल है और आपको हर डिप्लॉय पर ये वैल्यू ओवरराइड नहीं करनी हैं, तो 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 22 (झलक)
Node.js 20
Node.js 18

Node.js के 14 और 16 वर्शन का इस्तेमाल बंद कर दिया गया है. इन्हें 2025 की शुरुआत में बंद कर दिया जाएगा. इन वर्शन का इस्तेमाल करके डिप्लॉयमेंट करने की सुविधा बंद कर दी गई है.

Node.js का वर्शन सेट करने के लिए:

वर्शन को package.json फ़ाइल के engines फ़ील्ड में सेट किया जा सकता है. यह फ़ाइल, शुरू करने के दौरान आपकी functions/ डायरेक्ट्री में बनाई गई थी. उदाहरण के लिए, सिर्फ़ वर्शन 18 का इस्तेमाल करने के लिए, package.json में इस लाइन में बदलाव करें:

  "engines": {"node": "20"}

अगर Yarn पैकेज मैनेजर का इस्तेमाल किया जा रहा है या engines फ़ील्ड के लिए आपकी कुछ और ज़रूरी शर्तें हैं, तो firebase.json में Cloud Functions के लिए Firebase SDK टूल का रनटाइम सेट किया जा सकता है:

  {
    "functions": {
      "runtime": "nodejs18" // or nodejs20
    }
  }

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

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

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

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

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

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

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

स्केलिंग के व्यवहार को कंट्रोल करना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Node.js

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
  }
);

Python

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

ध्यान दें: कम से कम इंस्टेंस चलाने पर, बिलिंग की लागत, इंस्टेंस के इस्तेमाल में न होने पर लगने वाली दरों के हिसाब से तय की जाती है. 1st gen के लिए डिफ़ॉल्ट रूप से 256MiB मेमोरी असाइन करने की सुविधा के साथ, उसकी कीमत करीब 3 डॉलर/महीना होगी (gcf_gen_1 सीपीयू असाइन होने के साथ और एक साथ काम करने की सुविधा बंद होने पर) या 1 सीपीयू के साथ और एक साथ कई काम करने की सुविधा चालू होने पर, करीब 8 डॉलर/महीना. Firebase CLI, डिप्लॉयमेंट के समय उन फ़ंक्शन के लिए लागत का अनुमान देता है जिनके लिए कम से कम इंस्टेंस रिज़र्व किए गए हैं. कीमत का हिसाब लगाने के लिए, Cloud Run की कीमत देखें.

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

अगर 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 इंस्टेंस की सीमा सेट करता है, ताकि किसी संभावित लेगसी डेटाबेस को ज़्यादा लोड न किया जाए:

Node.js

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

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

Python

@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 फ़ंक्शन 1 जीबी मेमोरी का इस्तेमाल करता है और 300 सेकंड के बाद टाइम आउट हो जाता है:

Node.js

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

Python

@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 या 9 मिनट हो सकती है.

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

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

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

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

तय की गई रैम	वर्शन 1 का डिफ़ॉल्ट सीपीयू (फ़्रैक्शनल)	वर्शन 2 का डिफ़ॉल्ट सीपीयू	हर एमएस के हिसाब से कीमत में बढ़ोतरी
128 एमबी	1/12	1	10.5x
256 एमबी	6/1	1	5.3 गुना
512 एमबी	1/3	1	2.7x
1GB	7/12	1	1.6x
2 जीबी	1	1	1x
4 जीबी	2	2	1x
8 जीबी	2	2	1x
16 जीबी	लागू नहीं	4	लागू नहीं

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

Node.js

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

Python

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

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

Node.js

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

Python

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