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

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

• यह कमांड, सभी इलाकों में उस नाम से मेल खाने वाले सभी फ़ंक्शन मिटा देती है:

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

सीएलआई, 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. सभी फ़ंक्शन फिर से डिप्लॉय करें.

Node.js मॉड्यूल सिस्टम चुनना

Node.js में डिफ़ॉल्ट मॉड्यूल सिस्टम CommonJS (CJS) है. हालांकि, Node.js के मौजूदा वर्शन में ECMAScript Modules (ESM) का भी इस्तेमाल किया जा सकता है. 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 Cloud Functions के लिए SDK के 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 (2nd gen) में एक साथ कई अनुरोध प्रोसेस करने की सेटिंग के साथ एक्सपेरिमेंट करते समय, इन बातों का ध्यान रखें:

• एक साथ कई टास्क करने की सेटिंग को ज़्यादा पर सेट करने पर, सीपीयू और रैम का इस्तेमाल ज़्यादा हो सकता है. इससे परफ़ॉर्मेंस बेहतर हो सकती है. हालांकि, ऐसा तब तक होगा, जब तक कि सीपीयू और रैम का इस्तेमाल एक तय सीमा तक न पहुंच जाए. उदाहरण के लिए, इमेज या वीडियो को प्रोसेस करने वाले किसी फ़ंक्शन के पास, एक साथ 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 { 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 का डिफ़ॉल्ट सेवा खाता कहा जाता है)
• पहली जनरेशन के फ़ंक्शन: 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) में सेट किया जा सकता है. इसके लिए, इन ज़्यादा से ज़्यादा अवधि की सीमाओं के अंदर टाइम आउट वैल्यू का इस्तेमाल करें:

• एचटीटीपी और कॉल किए जा सकने वाले फ़ंक्शन: 3600 सेकंड (60 मिनट)
• शेड्यूल किए गए/टास्क क्यू फ़ंक्शन: 1800 सेकंड (30 मिनट)
• इवेंट पर आधारित अन्य फ़ंक्शन: 540 सेकंड (9 मिनट)

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

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

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

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

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

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

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

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

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

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