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

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 को क्लीनअप नीति सेट अप करने से रोकता है.

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

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

  • Firebase सीएलआई में functions:delete के साथ साफ़ तौर पर सेट किया गया हो

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

इंप्लिसिट फ़ंक्शन मिटाने की सुविधा की मदद से, 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

किसी फ़ंक्शन के लिए चुने गए क्षेत्र को बदलना

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

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

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

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

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 कंसोल या 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",
   ...
  }

इसे सेट करने के बाद, ESM 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 से 1,000 के बीच के किसी भी पूर्णांक पर सेट किया जा सकता है.

ज़्यादा कॉनकरेंसी सेटिंग वाले फ़ंक्शन, कोल्ड स्टार्ट के बिना भी ट्रैफ़िक में होने वाली बढ़ोतरी को मैनेज कर सकते हैं. इसकी वजह यह है कि हर इंस्टेंस में कुछ हेडरूम होने की संभावना होती है. अगर किसी इंस्टेंस को एक साथ 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 के दिशा-निर्देश भी देखे जा सकते हैं.
  • प्रोडक्शन में मल्टीकॉन्करंसी पर स्विच करने से पहले, टेस्ट एनवायरमेंट में मल्टीकॉन्करंसी की अच्छी तरह से जांच कर लें.

कम से कम इंस्टेंस को वॉर्म रखें

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

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:

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

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

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 के रिस्पॉन्स कोड के साथ अस्वीकार कर दिया जाता है.

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

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

फ़ंक्शन के लिए डिफ़ॉल्ट सेवा खातों के पास कई अनुमतियां होती हैं. इनकी मदद से, 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 सेकंड के बाद टाइम आउट हो जाता है:

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.

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

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

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

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

असाइन की गई रैम वर्शन 1 का डिफ़ॉल्ट सीपीयू (फ़्रैक्शनल) वर्शन 2 का डिफ़ॉल्ट सीपीयू हर एमएस के लिए कीमत में बढ़ोतरी
128 एमबी 1/12 1 10.5x
256 जीबी 1/6 1 5.3x
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 लागू नहीं

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

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