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

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

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

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

firebase deploy --only functions

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

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

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

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

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

ניקוי של ארטיפקטים של פריסה

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

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

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

אפשר להגדיר או לערוך מדיניות ניקוי באופן ידני באמצעות הפקודה functions:artifacts:setpolicy:

firebase functions:artifacts:setpolicy

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

אפשר להתאים אישית את תקופת השמירה באמצעות האפשרות --days:

firebase functions:artifacts:setpolicy --days 7  # Delete images older than 7 days

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

$ firebase functions:artifacts:setpolicy --location europe-west1

ביטול ההסכמה לניקוי פריטי מידע שנוצרו בתהליך פיתוח (Artifact)

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

$ firebase functions:artifacts:setpolicy --none

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

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

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

• באופן מפורש ב-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. מוחקים במפורש את הפונקציה הישנה מסביבת הייצור באמצעות Firebase CLI.

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

// 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 או gcloud CLI).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

התרת בקשות מקבילות

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

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

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

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

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

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

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

עד 2GB של זיכרון מוקצים לכל פונקציה ב-Cloud Functions for Firebase (דור שני), ומוקצה לה מעבד אחד כברירת מחדל, ואז היא גדלה ל-2 מעבדים ל-4GB ו-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