ניהול פונקציות

אפשר לפרוס, למחוק ולשנות פונקציות באמצעות פקודות CLI של Firebase או על ידי הגדרת אפשרויות של זמן ריצה בקוד המקור של הפונקציות.

פריסת פונקציות

כדי לפרוס פונקציות, מריצים את פקודת ה-CLI הבאה של Firebase:

firebase deploy --only functions

כברירת מחדל, CLI של Firebase פורס את כל הפונקציות שבמקור בו-זמנית. אם הפרויקט מכיל יותר מ-5 פונקציות, מומלץ להשתמש בדגל --only עם שמות פונקציות ספציפיים כדי לפרוס רק את הפונקציות שערכתם. פריסה של פונקציות ספציפיות בדרך הזו מזרזת את תהליך הפריסה ומונעת מצב שבו תגיעו למכסות הפריסה. לדוגמה:

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

כשפורסים מספר גדול של פונקציות, יכול להיות שתחרגו מהמכסה הרגילה ותקבלו הודעות שגיאה מסוג HTTP 429 או 500. כדי לפתור את הבעיה, כדאי לפרוס פונקציות בקבוצות של 10 פונקציות או פחות.

במאמרי העזרה של CLI של Firebase יש רשימה מלאה של הפקודות הזמינות.

כברירת מחדל, ה-CLI של Firebase מחפש את קוד המקור בתיקייה functions/. אם מעדיפים, אפשר לארגן פונקציות במסדי קוד או בכמה קבוצות של קבצים.

מחיקת פונקציות

אפשר למחוק פונקציות שפרסמתם בעבר בדרכים הבאות:

• באופן מפורש ב-CLI של Firebase באמצעות functions:delete
• בצורה מפורשת במסוף Google Cloud.
• באופן משתמע על ידי הסרת הפונקציה מהמקור לפני הפריסה.

בכל פעולת מחיקה תתבקשו לאשר לפני הסרת הפונקציה מסביבת הייצור.

מחיקה מפורשת של פונקציה ב-CLI של Firebase תומכת במספר ארגומנטים וגם בקבוצות של פונקציות, ומאפשרת לציין פונקציה שפועלת באזור מסוים. אפשר גם לשנות את ההנחיה לאישור.

# Delete all functions that match the specified name in all regions.
firebase functions:delete myFunction

# Delete a specified function running in a specific region.
firebase functions:delete myFunction --region us-east-1

# Delete more than one function
firebase functions:delete myFunction myOtherFunction

# Delete a specified functions group.
firebase functions:delete groupA

# Bypass the confirmation prompt.
firebase functions:delete myFunction --force

כשמשתמשים במחיקה משתמעת של פונקציות, firebase deploy מנתח את המקור ומסיר מהייצור את כל הפונקציות שהוסרו מהקובץ.

שינוי השם, האזור או הטריגר של פונקציה

אם אתם משנים את השם או את האזורים או את הטריגר של פונקציות שמטפלות בתנועה בסביבת הייצור, עליכם לפעול לפי השלבים שמפורטים בקטע הזה כדי להימנע מאובדן אירועים במהלך השינוי. לפני שמבצעים את השלבים האלה, צריך לוודא שהפונקציה עקבית, כי גם הגרסה החדשה וגם הגרסה הישנה של הפונקציה יפעלו בו-זמנית במהלך השינוי.

שינוי שם של פונקציה

כדי לשנות את השם של פונקציה, יוצרים גרסה חדשה של הפונקציה עם השם החדש במקור, ואז מריצים שתי פקודות פריסה נפרדות. הפקודה הראשונה פורסת את הפונקציה עם השם החדש, והפקודה השנייה מסירה את הגרסה שפרסמתם בעבר. לדוגמה, אם יש לכם webhook שמופעל על ידי 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. מוחקים את הפונקציה הקודמת.

לדוגמה, אם יש לכם פונקציה שמופעל עליה טריגר 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. מוחקים באופן מפורש את הפונקציה הישנה מהייצור באמצעות ה-CLI 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 או ה-CLI של gcloud).

אם תהליך הפיתוח שלכם כולל הגדרה ידנית של אפשרויות בסביבת זמן הריצה דרך מסוף Google Cloud או ה-CLI של gcloud, ואתם לא רוצים שהערכים האלה יבוטל בכל פריסה, צריך להגדיר את האפשרות preserveExternalChanges לערך true. כשהאפשרות הזו מוגדרת ל-true, מערכת Firebase משלבת את אפשרויות סביבת זמן הריצה שמוגדרות בקוד עם ההגדרות של הגרסה הנוכחית של הפונקציה שנפרסה, לפי סדר העדיפויות הבא:

1. האפשרות מוגדרת בקוד הפונקציות: שינוי של שינויים חיצוניים.
2. האפשרות מוגדרת כ-RESET_VALUE בקוד הפונקציות: שינוי חיצוני יבוטל על ידי ערך ברירת המחדל.
3. האפשרות לא מוגדרת בקוד הפונקציות, אבל היא מוגדרת בפונקציה הנוכחית שנפרסה: משתמשים באפשרות שצוינה בפונקציה שנפרסה.

לא מומלץ להשתמש באפשרות preserveExternalChanges: true ברוב התרחישים, כי הקוד לא יהיה יותר המקור המלא לאמת לגבי אפשרויות זמן הריצה של הפונקציות. אם אתם משתמשים בה, תוכלו לבדוק את ההגדרה המלאה של הפונקציה במסוף Google Cloud או באמצעות ה-CLI של gcloud.

הגדרת גרסת Node.js

ערכת ה-SDK של Firebase עבור Cloud Functions מאפשרת לבחור סביבת זמן ריצה של Node.js. אתם יכולים להפעיל את כל הפונקציות בפרויקט באופן בלעדי בסביבת זמן הריצה שתואם לאחת מגרסאות Node.js הנתמכות הבאות:

• Node.js 22 (תצוגה מקדימה)
• Node.js 20
• Node.js 18

גרסאות 14 ו-16 של Node.js הוצאו משימוש ונוציא משימוש בתחילת 2025. הפריסה עם הגרסאות האלה שהוצאו משימוש מושבתת.

כדי להגדיר את גרסת Node.js:

אפשר להגדיר את הגרסה בשדה engines בקובץ package.json שנוצר בתיקייה functions/ במהלך האיפוס. לדוגמה, כדי להשתמש רק בגרסה 18, עורכים את השורה הזו ב-package.json:

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

אם אתם משתמשים במנהל חבילות Yarn או שיש לך דרישות ספציפיות אחרות לשדה engines, תוכלו להגדיר את זמן הריצה של Firebase SDK של Cloud Functions ב-firebase.json במקום זאת:

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

ה-CLI משתמש בערך שמוגדר ב-firebase.json במקום בערך או בטווח שתגדירו בנפרד ב-package.json.

שדרוג זמן הריצה של Node.js

כדי לשדרג את סביבת זמן הריצה של Node.js:

1. חשוב לוודא שהפרויקט נכלל בתוכנית התמחור של Bllaze.
2. אתם צריכים לוודא שאתם משתמשים ב-CLI של Firebase מגרסה 11.18.0 ואילך.
3. משנים את הערך engines בקובץ package.json שנוצר בספרייה functions/ במהלך האתחול. לדוגמה, אם משדרגים מגרסה 18 לגרסה 20, הרשומה צריכה להיראות כך: "engines": {"node": "20"}
4. אפשר גם לבדוק את השינויים באמצעות Firebase Local Emulator Suite.
5. פורסים מחדש את כל הפונקציות.

הגדרת גרסת Python

Firebase SDK ל-Cloud Functions בגרסאות 12.0.0 ואילך אפשר לבחור את זמן הריצה של Python. מגדירים את גרסת סביבת זמן הריצה ב-firebase.json כפי שמוצג:

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

שליטה בהתנהגות ההתאמה לעומס

כברירת מחדל, Cloud Functions for Firebase משתנה בהתאם למספר הבקשות הנכנסות, כך שיכול להיות שהוא יגיע לאפס מכונות בזמנים של תנועה מופחתת. עם זאת, אם האפליקציה שלכם דורשת זמן אחזור קצר יותר ואתם רוצים להגביל את מספר ההפעלות מחדש, תוכלו לשנות את התנהגות ברירת המחדל הזו על ידי ציון מספר מינימלי של מכונות קונטיינר שיישמרו במצב פעילות מוכנה כדי להגיש בקשות.

באופן דומה, אפשר להגדיר מספר מקסימלי כדי להגביל את ההתאמה לעומס (scaling) של המכונות בתגובה לבקשות נכנסות. תוכלו להשתמש בהגדרה הזו כדי לשלוט בעלויות או להגביל את מספר החיבורים לשירות גיבוי, כמו למסד נתונים.

באמצעות ההגדרות האלה, יחד עם ההגדרה concurrency לכל מכונה (חדשה בדור השני), אפשר לשלוט בהתנהגות ההתאמה לעומס של הפונקציות ולכוונן אותה. הטבע של האפליקציה והפונקציה יקבעו אילו הגדרות יהיו הכי חסכוניות ויניבו את הביצועים הטובים ביותר.

באפליקציות מסוימות עם נפח תנועה נמוך, עדיף לבחור באפשרות של מעבד עם ביצועים נמוכים יותר ללא ריבוי משימות בו-זמנית. בשירותים אחרים שבהם הפעלה מחדש היא בעיה קריטית, הגדרת מספר רב של מופעים וזמן פעילות מקסימלי מאפשרת לשמור תמיד על קבוצה של מופעים במצב פעיל כדי לטפל בעליות חדות גדולות בנפח התנועה.

באפליקציות בקנה מידה קטן שמקבלות מעט מאוד תנועה, הגדרת מספר קטן של מכונות מקסימליות עם רמת בו-זמניות גבוהה מאפשרת לאפליקציה לטפל בתנודות חדות בנפח התנועה בלי להוביל לעלויות מיותרות. עם זאת, חשוב לזכור שאם מספר המכונות המקסימלי נמוך מדי, הבקשות עשויות להתבטל כשמגיעים לתקרה.

אישור בקשות בו-זמנית

ב-Cloud Functions for Firebase (דור ראשון), כל מכונה יכלה לטפל בבקשה אחת בכל פעם, ולכן התנהגות ההתאמה לעומס הוגדרה רק באמצעות הגדרות המינימום והמקסימום של המכונות. בנוסף לשליטה במספר המופעים, ב-Cloud Functions for Firebase (דור שני) אפשר לשלוט במספר הבקשות שכל מכונה יכולה לטפל בהן בו-זמנית באמצעות האפשרות concurrency. ערך ברירת המחדל של בו-זמניות הוא 80, אבל אפשר להגדיר אותו לכל מספר שלם בין 1 ל-1,000.

פונקציות עם הגדרות גבוהות יותר של בו-זמניות יכולות לספוג עליות חדות בתעבורת נתונים בלי הפעלה במצב התחלתי (cold start), כי סביר להניח שלכל מכונה יש מספיק מרחב. אם מכונה מוגדרת לטפל בעד 50 בקשות בו-זמנית אבל כרגע מטפלת רק ב-25, היא יכולה להתמודד עם עלייה חדה של 25 בקשות נוספות בלי שתצטרכו להפעיל מכונה חדשה להפעלה במצב התחלתי (cold start). לעומת זאת, עם הגדרת בו-זמניות (1) בלבד, העלייה הזו בבקשות עשויה להוביל ל-25 הפעלות במצב התחלתי (cold start).

התרחיש הפשוט הזה מדגים את היתרונות הפוטנציאליים של בו-זמניות. בפועל, התהליך של שינוי ההתנהגות בהתאם לעומס כדי לשפר את היעילות ולהפחית את מספר ההפעלות מחדש (cold start) במקביל הוא מורכב יותר. התכונה 'ביצועים בו-זמנית' ב-Cloud Functions for Firebase מדור שני מבוססת על Cloud Run ופועלת לפי הכללים של Cloud Run בנושא שינוי אוטומטי של קנה המידה של מכונות בקונטיינרים.

כשאתם עורכים ניסויים עם הגדרות של ריבוי משימות בו-זמנית (concurrency) ברמה גבוהה יותר ב-Cloud Functions for Firebase (דור שני), חשוב לזכור את הנקודות הבאות:

• הגדרות של ריבוי משימות (concurrency) גבוה יותר עשויות לדרוש יותר מעבד (CPU) ו-RAM כדי להגיע לביצועים אופטימליים, עד שמגיעים למגבלה מעשית. לדוגמה, יכול להיות שלפונקציה שמבצעת עיבוד תמונות או סרטונים אינטנסיבי לא יהיו המשאבים הדרושים כדי לטפל ב-1,000 בקשות בו-זמנית, גם אם הגדרות המעבד וה-RAM שלה מוגדרות למקסימום.
• מכיוון ש-Cloud Functions for Firebase (דור שני) פועל על Cloud Run, אפשר לעיין גם בהנחיות ל-Google Cloud בנושא אופטימיזציה של בו-זמניות.
• חשוב לבצע בדיקה יסודית של ריבוי מטבעות בסביבת בדיקה לפני שעוברים לשימוש בכמה מטבעות בו-זמנית בסביבת הייצור.

שמירה על מספר מינימלי של מכונות במצב 'מופעל'

אפשר להגדיר מספר מינימלי של מכונות לפונקציה בקוד המקור. לדוגמה, הפונקציה הזו מגדירה 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:

כמה דברים שחשוב לקחת בחשבון כשמגדירים ערך מינימלי של מכונות:

• אם Cloud Functions for Firebase יאכלס את האפליקציה מעבר להגדרה שלכם, תהיה הפעלה קרה (cold start) בכל מכונה מעבר לסף הזה.
• הפעלה במצב התחלתי (cold start) משפיעה בצורה הכי חמורה על אפליקציות עם תנועה קוצנית. אם באפליקציה יש עליות חדות בנפח התנועה, והגדרתם ערך גבוה מספיק כדי לצמצם את מספר הפעמים שהאפליקציה תופעל מחדש בכל עלייה בנפח התנועה, זמן האחזור יצומצם באופן משמעותי. באפליקציות עם תנועה קבועה, סביר להניח שהפעלות מצב התחלתי לא ישפיעו באופן משמעותי על הביצועים.

• הגדרת מספר מינימלי של מכונות יכולה להיות הגיונית בסביבות ייצור, אבל בדרך כלל יש להימנע ממנה בסביבות בדיקה. כדי לשנות את רמת התאמת הקיבולת לאפס בפרויקט הבדיקה, אבל עדיין לצמצם את זמן ההפעלה מחדש בפרויקט הייצור, אפשר להגדיר ערך מינימלי למכונות בהגדרה עם הפרמטרים:

  Node.js

  const functions = require('firebase-functions/v1');
  const { defineInt, defineString } = require('firebase-functions/params');
  
  // Define some parameters
  const minInstancesConfig = defineInt('HELLO_WORLD_MININSTANCES');
  const welcomeMessage = defineString('WELCOME_MESSAGE');
  
  // To use configured parameters inside the config for a function, provide them 
  // directly. To use them at runtime, call .value() on them.
  export const helloWorld = functions.runWith({ minInstances: minInstancesConfig}).https.onRequest(
    (req, res) => {
      res.send(`${welcomeMessage.value()}! I am a function.`);
    }
  );
  

  Python

  MIN_INSTANCES = params.IntParam("HELLO_WORLD_MININSTANCES")
  WELCOME_MESSAGE = params.StringParam("WELCOME_MESSAGE")
  
  @https_fn.on_request(min_instances=MIN_INSTANCES.value())
  def get_autocomplete_response(event: https_fn.Request) -> https_fn.Response:
      return https_fn.Response(f"{WELCOME_MESSAGE.value()} I'm a function.")
  

הגבלת מספר המופעים המקסימלי של פונקציה

אפשר להגדיר ערך למספר המופעים המקסימלי בקוד המקור של הפונקציה. לדוגמה, הפונקציה הזו מגדירה מגבלה של 100 מופעים כדי לא להעמיס על מסד נתונים היפותטי מדור קודם:

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 Cloud או בקוד המקור של הפונקציה (ב-Firebase בלבד).

כדי להגדיר הקצאת זיכרון ותקופת זמן קצובה לתפוגה בקוד המקור של הפונקציות, אפשר להשתמש באפשרויות הגלובליות של זיכרון ושל שניות זמן קצוב לתפוגה כדי להתאים אישית את המכונה הווירטואלית שמריצה את הפונקציות. לדוגמה, הפונקציה Cloud Storage משתמשת ב-1GB של זיכרון ותוקף הזמן שלה פג אחרי 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 Cloud:

1. במסוף Google Cloud, בוחרים באפשרות Cloud Functions for Firebase בתפריט הימני.
2. לוחצים על השם של הפונקציה ברשימה כדי לבחור אותה.
3. לוחצים על הסמל עריכה בתפריט העליון.
4. בוחרים הקצאת זיכרון מהתפריט הנפתח Memory allocated.
5. לוחצים על More כדי להציג את האפשרויות המתקדמות ומזינים מספר שניות בתיבת הטקסט זמן קצוב לתפוגה.
6. לוחצים על Save כדי לעדכן את הפונקציה.

שינוי ברירות המחדל של המעבד (CPU)

הקצאת זיכרון בנפח של עד 2GB, וכל פונקציה בCloud Functions for Firebase (דור שני) בוחרת כברירת מחדל למעבד אחד (CPU) ואז עולה ל-2 מעבדים (CPU) ל-4 ול-8GB. חשוב לזכור שההתנהגות הזו שונה באופן משמעותי מברירת המחדל של הדור הראשון, ויכול להיות שהיא תוביל לעלויות גבוהות יותר במעט לפונקציות עם נפח זיכרון נמוך, כפי שמתואר בטבלה הבאה:

אם אתם מעדיפים את ההתנהגות של פונקציות מדור ראשון בפונקציות מדור שני, צריך להגדיר את ברירת המחדל של פונקציות מדור ראשון כאפשרות גלובלית:

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

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

לפונקציות שמשתמשות ב-CPU באופן אינטנסיבי, הדור השני מספק את הגמישות להגדיר מעבדים נוספים. אפשר לשפר את מעבד ה-CPU לפי פונקציה, כפי שמוצג:

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