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

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

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

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

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

firebase deploy --only functions

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

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

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

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

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

כדי להגדיר את גרסת 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:

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

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

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

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

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

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

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

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

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

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

הגדרות בו-זמניות גבוהות עשויות לדרוש מעבד (CPU) ו-RAM גבוהים יותר לביצועים אופטימליים, עד שמגיעים למגבלה מעשית. לדוגמה, יכול להיות שלפונקציה שמבצעת עיבוד תמונות או סרטונים אינטנסיבי לא יהיו המשאבים הדרושים כדי לטפל ב-1,000 בקשות בו-זמנית, גם אם הגדרות המעבד וה-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 Run

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

אם 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 מופעים כדי לא להעמיס על מסד נתונים היפותטי מדור קודם:

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 משתמשת ב-1GB של זיכרון ותוקף הזמן שלה פג אחרי 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 מהתפריט השמאלי.
בוחרים פונקציה על ידי לחיצה על השם שלה ברשימת הפונקציות.
לוחצים על סמל העריכה בתפריט העליון.
בוחרים הקצאת זיכרון מהתפריט הנפתח Memory allocated.
לוחצים על עוד כדי להציג את האפשרויות המתקדמות, ומזינים מספר שניות בתיבה Timeout.
לוחצים על Save כדי לעדכן את הפונקציה.

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

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

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

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

Node.js

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

Python

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

לפונקציות שצורכות הרבה מעבד (CPU), הדור השני מספק גמישות להגדרת מעבד (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