דף זה תורגם על ידי Cloud Translation API.

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

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

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

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

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, ואתם רוצים לשנות את הקוד באופן הבא:

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

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

אם אתם משנים את האזורים שצוינו עבור שמטפל בתנועה לסביבת הייצור, אפשר למנוע אובדן אירועים באמצעות ביצוע השלבים הבאים לפי הסדר:

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

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

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

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

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

לא מומלץ להשתמש באפשרות 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. Deployment (פריסה) בגרסאות שהוצאו משימוש מושבתות.

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

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

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

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

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

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

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

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

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

הגדרת גרסת Python

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

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

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

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

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

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

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

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

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

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

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

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

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

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

חשוב לשמור על מספר מינימלי של מופעים חמים

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

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 יאכלס את האפליקציה מעבר להגדרה שלכם, תהיה הפעלה קרה (cold start) בכל מכונה מעבר לסף הזה.
הפעלות ראשוניות (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 מכונות כדי להציף מסד נתונים היפותטי מדור קודם:

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

אם ההתאמה של פונקציית HTTP תגיע למגבלת המכונות המקסימלית, בקשות חדשות הועבר לתור למשך 30 שניות ולאחר מכן נדחה עם קוד תגובה 429 Too Many Requests אם לא תהיה אף מכונה זמינה עד אז.

שיטות מומלצות להגדרת מספר מכונות מקסימלי

הגדרה של זמן קצוב לתפוגה והקצאת זיכרון

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

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

הערך המקסימלי של זמן הקצוב לתפוגה בשניות הוא 540, או 9 דקות.

כדי להגדיר הקצאת זיכרון וזמן קצוב לתפוגה במסוף Google Cloud:

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

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

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

הקצאת זיכרון RAM	מעבד (CPU) שמוגדר כברירת מחדל בגרסה 1 (חלקי)	מעבד (CPU) שמוגדר כברירת מחדל בגרסה 2	עליית מחיר לכל אלפית שנייה
128MB	1/12	1	פי 10.5
256MB	1/6	1	5.3x
512MB	1/3	1	פי 2.7
1GB	12/7	1	1.6x
2GB	1	1	1x
4GB	2	2	1x
8GB	2	2	1x
16 GB	לא רלוונטי	4	לא רלוונטי

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

Node.js

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

Python

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

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

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