फ़ंक्शन प्रबंधित करें

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

कार्यों को तैनात करें

फ़ंक्शंस को तैनात करने के लिए, यह फ़ायरबेस सीएलआई कमांड चलाएँ:

firebase deploy --only functions

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

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

बड़ी संख्या में फ़ंक्शन तैनात करते समय, आप मानक कोटा पार कर सकते हैं और HTTP 429 या 500 त्रुटि संदेश प्राप्त कर सकते हैं। इसे हल करने के लिए, फ़ंक्शंस को 10 या उससे कम के समूहों में तैनात करें।

उपलब्ध कमांड की पूरी सूची के लिए फायरबेस सीएलआई संदर्भ देखें।

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

फ़ंक्शंस हटाएं

आप पहले से तैनात फ़ंक्शंस को इन तरीकों से हटा सकते हैं:

• फ़ंक्शंस के साथ फ़ायरबेस सीएलआई में स्पष्ट रूप से functions:delete
• स्पष्ट रूप से Google क्लाउड कंसोल में।
• तैनाती से पहले स्रोत से फ़ंक्शन को हटाकर ।

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

फायरबेस सीएलआई में स्पष्ट फ़ंक्शन विलोपन कई तर्कों के साथ-साथ फ़ंक्शन समूहों का समर्थन करता है, और आपको किसी विशेष क्षेत्र में चल रहे फ़ंक्शन को निर्दिष्ट करने की अनुमति देता है। इसके अलावा, आप पुष्टिकरण संकेत को ओवरराइड कर सकते हैं।

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

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

यदि आप उत्पादन ट्रैफ़िक को संभालने वाले कार्यों के लिए क्षेत्रों या ट्रिगर का नाम बदल रहे हैं या बदल रहे हैं, तो संशोधन के दौरान घटनाओं को खोने से बचने के लिए इस अनुभाग में दिए गए चरणों का पालन करें। इन चरणों का पालन करने से पहले, सुनिश्चित करें कि आपका फ़ंक्शन निष्क्रिय है, क्योंकि परिवर्तन के दौरान आपके फ़ंक्शन का नया संस्करण और पुराना संस्करण दोनों एक ही समय पर चलेंगे।

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

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

// 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. पिछला फ़ंक्शन हटाएं.

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

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

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

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

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

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

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

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

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

सर्वोत्तम अभ्यास के रूप में, इन विकल्पों (Node.js संस्करण को छोड़कर) को फ़ंक्शन कोड के अंदर कॉन्फ़िगरेशन ऑब्जेक्ट पर सेट किया जाना चाहिए। यह RuntimeOptions ऑब्जेक्ट आपके फ़ंक्शन के रनटाइम विकल्पों के लिए सत्य का स्रोत है, और किसी अन्य विधि (जैसे Google क्लाउड कंसोल या gcloud CLI के माध्यम से) के माध्यम से सेट किए गए विकल्पों को ओवरराइड करेगा।

यदि आपके विकास वर्कफ़्लो में Google क्लाउड कंसोल या जीक्लाउड सीएलआई के माध्यम से मैन्युअल रूप से रनटाइम विकल्प सेट करना शामिल है और आप नहीं चाहते कि इन मानों को प्रत्येक तैनाती पर ओवरराइड किया जाए, तो preserveExternalChanges विकल्प को true पर सेट करें। इस विकल्प को true पर सेट करने के साथ, फायरबेस आपके कोड में सेट किए गए रनटाइम विकल्पों को निम्नलिखित प्राथमिकता के साथ आपके फ़ंक्शन के वर्तमान-तैनात संस्करण की सेटिंग्स के साथ विलय कर देता है:

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

अधिकांश परिदृश्यों के लिए preserveExternalChanges: true विकल्प का उपयोग करने की अनुशंसा नहीं की जाती है क्योंकि आपका कोड अब आपके कार्यों के लिए रनटाइम विकल्पों के लिए सत्य का पूर्ण स्रोत नहीं होगा। यदि आप इसका उपयोग करते हैं, तो फ़ंक्शन की पूर्ण कॉन्फ़िगरेशन देखने के लिए Google क्लाउड कंसोल की जांच करें या gcloud CLI का उपयोग करें।

Node.js संस्करण सेट करें

क्लाउड फ़ंक्शंस के लिए फ़ायरबेस SDK Node.js रनटाइम के चयन की अनुमति देता है। आप किसी प्रोजेक्ट में सभी फ़ंक्शन को विशेष रूप से इन समर्थित Node.js संस्करणों में से किसी एक के अनुरूप रनटाइम वातावरण पर चलाना चुन सकते हैं:

• नोड.जेएस 20 (पूर्वावलोकन)
• नोड.जेएस 18
• नोड.जेएस 16
• नोड.जेएस 14

Node.js संस्करण सेट करने के लिए:

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

  "engines": {"node": "18"}

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

  {
    "functions": {
      "runtime": "nodejs18" // or nodejs14, nodejs16 or nodejs20
    }
  }

सीएलआई आपके द्वारा package.json में अलग से सेट किए गए किसी भी मान या श्रेणी की प्राथमिकता में firebase.json में निर्धारित मान का उपयोग करता है।

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

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

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

पायथन संस्करण सेट करें

क्लाउड फ़ंक्शंस संस्करण 12.0.0 और उच्चतर के लिए फायरबेस एसडीके पायथन रनटाइम के चयन की अनुमति देता है। दिखाए गए अनुसार firebase.json में रनटाइम संस्करण सेट करें:

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

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

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

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

प्रति-इंस्टेंस समवर्ती सेटिंग (दूसरी पीढ़ी में नया) के साथ इन सेटिंग्स का उपयोग करके, आप अपने कार्यों के लिए स्केलिंग व्यवहार को नियंत्रित और ट्यून कर सकते हैं। आपके एप्लिकेशन और फ़ंक्शन की प्रकृति यह निर्धारित करेगी कि कौन सी सेटिंग्स सबसे अधिक लागत प्रभावी हैं और इसके परिणामस्वरूप सबसे अच्छा प्रदर्शन होगा।

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

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

समवर्ती अनुरोधों की अनुमति दें

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

उच्च समवर्ती सेटिंग्स वाले फ़ंक्शन बिना किसी रुकावट के ट्रैफ़िक के स्पाइक्स को अवशोषित कर सकते हैं क्योंकि प्रत्येक उदाहरण में कुछ हेडरूम होने की संभावना होती है। यदि किसी इंस्टेंस को 50 समवर्ती अनुरोधों को संभालने के लिए कॉन्फ़िगर किया गया है, लेकिन वर्तमान में केवल 25 को संभाल रहा है, तो यह कोल्ड स्टार्ट के लिए नए इंस्टेंस की आवश्यकता के बिना 25 अतिरिक्त अनुरोधों की वृद्धि को संभाल सकता है। इसके विपरीत, केवल 1 की समवर्ती सेटिंग के साथ, अनुरोधों में बढ़ोतरी से 25 कोल्ड स्टार्ट हो सकते हैं।

यह सरलीकृत परिदृश्य समवर्तीता के संभावित दक्षता लाभ को प्रदर्शित करता है। वास्तव में, दक्षता को अनुकूलित करने और समवर्तीता के साथ ठंड की शुरुआत को कम करने के लिए स्केलिंग व्यवहार अधिक जटिल है। फायरबेस द्वितीय पीढ़ी के लिए क्लाउड फ़ंक्शंस में कॉनकरेंसी क्लाउड रन द्वारा संचालित है, और कंटेनर इंस्टेंस ऑटोस्केलिंग के क्लाउड रन के नियमों का पालन करता है।

फायरबेस (दूसरी पीढ़ी) के लिए क्लाउड फ़ंक्शंस में उच्च समवर्ती सेटिंग्स के साथ प्रयोग करते समय, निम्नलिखित को ध्यान में रखें:

• उच्च समवर्ती सेटिंग्स को व्यावहारिक सीमा तक पहुंचने तक इष्टतम प्रदर्शन के लिए उच्च सीपीयू और रैम की आवश्यकता हो सकती है। उदाहरण के लिए, एक फ़ंक्शन जो भारी छवि या वीडियो प्रोसेसिंग करता है, उसमें 1000 समवर्ती अनुरोधों को संभालने के लिए संसाधनों की कमी हो सकती है, भले ही इसकी सीपीयू और रैम सेटिंग्स अधिकतम हो।
• चूंकि फायरबेस के लिए क्लाउड फ़ंक्शंस (दूसरी पीढ़ी) क्लाउड रन द्वारा संचालित है, आप समवर्ती अनुकूलन के लिए Google क्लाउड मार्गदर्शन का भी उल्लेख कर सकते हैं।
• उत्पादन में मल्टीकॉन्करेंसी पर स्विच करने से पहले एक परीक्षण वातावरण में मल्टीकॉन्करेंसी का अच्छी तरह से परीक्षण करना सुनिश्चित करें।

कम से कम संख्या में उदाहरण गर्म रखें

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

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:

न्यूनतम इंस्टेंस मान सेट करते समय विचार करने योग्य कुछ बातें यहां दी गई हैं:

• यदि फायरबेस के लिए क्लाउड फ़ंक्शंस आपके ऐप को आपकी सेटिंग से ऊपर रखता है, तो आपको उस सीमा से ऊपर प्रत्येक इंस्टेंस के लिए एक ठंडी शुरुआत का अनुभव होगा।
• तेज़ ट्रैफ़िक वाले ऐप्स पर कोल्ड स्टार्ट का सबसे गंभीर प्रभाव पड़ता है। यदि आपके ऐप में बहुत अधिक ट्रैफ़िक है और आपने इतना अधिक मान सेट किया है कि प्रत्येक ट्रैफ़िक वृद्धि पर कोल्ड स्टार्ट कम हो जाए, तो आपको विलंबता में काफी कमी दिखाई देगी। लगातार ट्रैफ़िक वाले ऐप्स के लिए, कोल्ड स्टार्ट से प्रदर्शन पर गंभीर प्रभाव पड़ने की संभावना नहीं है।

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

  नोड.जे.एस

  const functions = require('firebase-functions');
  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.`);
    }
  );
  

  अजगर

  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

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

अधिकतम इंस्टेंस सेटिंग्स का उपयोग करने के लिए सर्वोत्तम प्रथाओं के बारे में अधिक जानने के लिए, अधिकतम इंस्टेंसेस सेट करने के लिए इन सर्वोत्तम प्रथाओं को देखें।

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

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

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

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

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

टाइमआउट सेकंड का अधिकतम मान 540 या 9 मिनट है।

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

1. Google क्लाउड कंसोल में बाएं मेनू से फायरबेस के लिए क्लाउड फ़ंक्शंस चुनें।
2. फ़ंक्शन सूची में किसी फ़ंक्शन के नाम पर क्लिक करके उसका चयन करें।
3. शीर्ष मेनू में संपादन आइकन पर क्लिक करें।
4. मेमोरी आवंटित लेबल वाले ड्रॉप-डाउन मेनू से मेमोरी आवंटन का चयन करें।
5. उन्नत विकल्प प्रदर्शित करने के लिए अधिक पर क्लिक करें, और टाइमआउट टेक्स्ट बॉक्स में कई सेकंड दर्ज करें।
6. फ़ंक्शन को अद्यतन करने के लिए सहेजें पर क्लिक करें।

सीपीयू डिफ़ॉल्ट को ओवरराइड करें

2 जीबी तक आवंटित मेमोरी, फायरबेस (दूसरी पीढ़ी) के लिए क्लाउड फ़ंक्शंस में प्रत्येक फ़ंक्शन एक सीपीयू पर डिफ़ॉल्ट होता है, और फिर 4 और 8 जीबी के लिए 2 सीपीयू तक बढ़ जाता है। ध्यान दें कि यह पहली पीढ़ी के डिफ़ॉल्ट व्यवहार से काफी भिन्न है, जिससे निम्न-मेमोरी कार्यों के लिए थोड़ी अधिक लागत हो सकती है, जैसा कि निम्नलिखित तालिका में व्यक्त किया गया है:

यदि आप अपनी दूसरी पीढ़ी के कार्यों के लिए पहली पीढ़ी के व्यवहार को प्राथमिकता देते हैं, तो पहली पीढ़ी के डिफ़ॉल्ट को वैश्विक विकल्प के रूप में सेट करें:

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