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

דור שני דור ראשון

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

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

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

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

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

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

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

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, תוכלו להגדיר את סביבת זמן הריצה של ה-SDK של Firebase עבור Cloud Functions ב-firebase.json במקום זאת:

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

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

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

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

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

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

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

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

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

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

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

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

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

חשוב: יכולת ביצוע בו-זמנית זמינה רק לפונקציות עם לפחות מעבד אחד מלא. הגדרת המעבד של פונקציה לערך עשרוני או הגדרת המעבד לערך gcf_gen1 לפונקציה עם פחות מ-2GB של זיכרון RAM משביתה את התכונה 'ביצוע בו-זמנית'. מידע נוסף זמין במאמר שינוי של הגדרות ברירת המחדל של המעבד.

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

• הגדרות של ריבוי משימות (concurrency) גבוה יותר עשויות לדרוש יותר מעבד (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:

הערה: מספר מינימלי של מכונות שפועלות יגרמו לחיוב בעלויות במצב חוסר פעילות. פונקציה עם הקצאת זיכרון שמוגדרת כברירת מחדל ל-256MiB בדור הראשון עולה כ-3 $לחודש (עם הקצאת מעבד gcf_gen_1 והפעלת מרובות משימות מושבתת) או כ-8 $לחודש עם מעבד אחד והפעלת מרובות משימות מופעלת. ה-CLI של Firebase מספק אומדן עלות בזמן הפריסה של פונקציות עם מכונות מינימום שמורות. כאן מוסבר איך מחשבים את העלויות.

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:

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

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

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

נפח ה-RAM שהוקצה	מעבד ברירת המחדל של גרסה 1 (חלקי)	מעבד ברירת המחדל של גרסה 2	עלייה במחיר לכל אלפית שנייה
128MB	1/12	1	פי 10.5
256MB	1/6	1	5.3x
512MB	1/3	1	2.7x
1GB	7/12	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