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

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

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

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

firebase deploy --only functions

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

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

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

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

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

डिप्लॉयमेंट आर्टफ़ैक्ट मिटाना

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

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

स्टोरेज की लागत को मैनेज करने के लिए, Firebase सीएलआई 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 सीएलआई की सेट की गई किसी भी मौजूदा क्लीनअप नीति को हटा देता है. साथ ही, फ़ंक्शन डिप्लॉय करने के बाद, Firebase को क्लीनअप नीति सेट अप करने से रोकता है.

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

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

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

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

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

• सभी क्षेत्रों में, दिए गए नाम से मैच होने वाले सभी फ़ंक्शन मिटाता है:

  firebase functions:delete FUNCTION-1_NAME

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

  firebase functions:delete FUNCTION-1_NAME --region REGION_NAME

• एक से ज़्यादा फ़ंक्शन मिटाता है:

  firebase functions:delete FUNCTION-1_NAME FUNCTION-2_NAME

• किसी फ़ंक्शन ग्रुप को मिटाता है:

  firebase functions:delete GROUP_NAME

• पुष्टि करने के लिए दिखने वाले प्रॉम्प्ट को बायपास करता है:

  firebase functions:delete FUNCTION-1_NAME --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 सीएलआई का इस्तेमाल करके, प्रोडक्शन से पुराने फ़ंक्शन को साफ़ तौर पर मिटाएं.

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

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

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

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

ज़्यादातर मामलों में, preserveExternalChanges: true विकल्प का इस्तेमाल करने का सुझाव नहीं दिया जाता. ऐसा इसलिए, क्योंकि आपका कोड अब आपके फ़ंक्शन के रनटाइम विकल्पों के लिए, पूरी तरह से सही सोर्स नहीं रहेगा. अगर इसका इस्तेमाल किया जाता है, तो Google Cloud कंसोल देखें या किसी फ़ंक्शन का पूरा कॉन्फ़िगरेशन देखने के लिए, 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
    }
  }

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

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

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

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

कोई Node.js मॉड्यूल सिस्टम चुनें

Node.js में डिफ़ॉल्ट मॉड्यूल सिस्टम CommonJS (CJS) है. हालांकि, Node.js के मौजूदा वर्शन, ECMAScript मॉड्यूल (ईएसएम) के साथ भी काम करते हैं. Cloud Functions, दोनों तरह के ऐप्लिकेशन के लिए काम करता है.

डिफ़ॉल्ट रूप से, आपके फ़ंक्शन CommonJS का इस्तेमाल करते हैं. इसका मतलब है कि इंपोर्ट और एक्सपोर्ट इस तरह दिखते हैं:

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

exports.helloWorld = onRequest(async (req, res) => res.send("Hello from Firebase!"));

इसके बजाय, ईएसएम का इस्तेमाल करने के लिए, अपनी package.json फ़ाइल में "type": "module" फ़ील्ड को सेट करें :

  {
   ...
   "type": "module",
   ...
  }

इसे सेट करने के बाद, ईएसएम import और export सिंटैक्स का इस्तेमाल करें:

import {onRequest} from "firebase-functions/https";

export const helloWorld = onRequest(async (req, res) => res.send("Hello from Firebase!"));

दोनों मॉड्यूल सिस्टम पूरी तरह से काम करते हैं. अपने प्रोजेक्ट के हिसाब से, सबसे सही विकल्प चुनें. ज़्यादा जानने के लिए, मॉड्यूल पर Node.js दस्तावेज़ देखें.

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

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

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

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

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

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

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

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

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

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

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 (2nd gen) को 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 { onRequest } = require('firebase-functions/https');
  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 = onRequest(
    { minInstances: minInstancesConfig },
  (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 के रिस्पॉन्स कोड के साथ अनुरोधों को अस्वीकार कर दिया जाता है.

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

सेवा खाता सेट करना

फ़ंक्शन के लिए डिफ़ॉल्ट सेवा खातों के पास कई अनुमतियां होती हैं. इनकी मदद से, Firebase और Google Cloud की अन्य सेवाओं के साथ इंटरैक्ट किया जा सकता है:

• दूसरी जनरेशन के फ़ंक्शन: PROJECT_NUMBER-compute@developer.gserviceaccount.com (इसका नाम Compute Engine का डिफ़ॉल्ट सेवा खाता है)
• 1st gen फ़ंक्शन: PROJECT_ID@appspot.gserviceaccount.com (इसका नाम App Engine का डिफ़ॉल्ट सेवा खाता है)

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

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

exports.helloWorld = onRequest(
    {
        // This function doesn't access other Firebase project resources, so it uses a limited service account.
        serviceAccount:
            "my-limited-access-sa@", // or prefer the full form: "my-limited-access-sa@my-project.iam.gserviceaccount.com"
    },
    (request, response) => {
        response.send("Hello from Firebase!");
    },
);

अगर आपको अपने सभी फ़ंक्शन के लिए एक ही सेवा खाता सेट करना है, तो setGlobalOptions फ़ंक्शन का इस्तेमाल करें.

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

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

• एचटीटीपी और कॉल किए जा सकने वाले फ़ंक्शन: 3,600 सेकंड (60 मिनट)
• शेड्यूल किए गए/टास्क सूची वाले फ़ंक्शन: 1,800 सेकंड (30 मिनट)
• इवेंट के हिसाब से ट्रिगर होने वाले अन्य फ़ंक्शन: 540 सेकंड (9 मिनट)

फ़ंक्शन के सोर्स कोड में मेमोरी का बंटवारा और टाइम आउट सेट करने के लिए, मेमोरी और टाइम आउट के लिए ग्लोबल विकल्पों का इस्तेमाल करें. इससे, आपके फ़ंक्शन चलाने वाली वर्चुअल मशीन को पसंद के मुताबिक बनाया जा सकता है. उदाहरण के लिए, यह Cloud Storage फ़ंक्शन 1 जीबी मेमोरी का इस्तेमाल करता है और 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.

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

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

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

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

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

// 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