בדף הזה מפורטות המגבלות שניתן להתאים לפי שימוש ב-Cloud Functions, בהתאם לתוכנית התמחור 'Blaze' בתשלום לפי שימוש. המגבלות האלה חלות על פרויקטים ב-Firebase שמפרסים פונקציות בסביבת זמן הריצה של Node.js 10.
בתוכנית Blaze מקבלים כמויות גדולות של קריאות, זמן מחשוב ותנועה באינטרנט ללא תשלום. עם זאת, פריסות של פונקציות גוררות חיובים קטנים על נפח האחסון שבו נעשה שימוש בקונטיינר של הפונקציה. מידע נוסף זמין בשאלות הנפוצות של Firebase.
המכסות ב-Google Cloud Functions כוללות 3 תחומים:
מגבלות על משאבים
הגורמים האלה משפיעים על כמות המשאבים הכוללת שהפונקציות יכולות לצרוך.
מגבלות זמן
הגורמים האלה משפיעים על משך הזמן שבו הדברים יכולים לפעול.
הגבלות קצב
הם משפיעים על הקצב שבו אפשר להפעיל את Cloud Functions API כדי לנהל את הפונקציות.
בהמשך מוסבר בהרחבה על סוגי המגבלות השונים. ההבדלים בין המגבלות של Cloud Functions (דור ראשון) לבין המגבלות של Cloud Functions (דור שני) מצוינים במקרים הרלוונטיים.
מגבלות של משאבים
מגבלות המשאבים משפיעות על כמות המשאבים הכוללת שהפונקציות יכולות לצרוך. ההיקף האזורי משתנה בהתאם לפרויקט, ולכל פרויקט יש מגבלות משלו.
מכסה | תיאור | Limit (דור ראשון) | Limit (דור שני) | אפשר להגדיל | היקף |
---|---|---|---|---|---|
מספר הפונקציות | המספר הכולל של הפונקציות שאפשר לפרוס בכל אזור | 1,000 | 1,000 פחות מספר שירותי Cloud Run שנפרסו | לא | לכל אזור |
גודל הפריסה המקסימלי | הגודל המקסימלי של פריסה של פונקציה אחת | 100MB (דחוסים) למקורות. 500MB (לא דחוס) למקורות וגם מודולים. |
לא רלוונטי | לא | לכל פונקציה |
הגודל המקסימלי של בקשת HTTP ללא דחיסה | נתונים שנשלחים לפונקציות HTTP בבקשת HTTP | 10MB | 32MB | לא | לכל הפעלה |
הגודל המקסימלי של תגובת HTTP לא דחוסה | נתונים שנשלחים מפונקציות HTTP בתגובת HTTP | 10MB | 10MB להצגת תשובות באופן שוטף. 32MB לתשובות שלא משודרות. |
לא | לכל הפעלה |
גודל אירוע מקסימלי לפונקציות מבוססות-אירוע | נתונים שנשלחים באירועים לפונקציות ברקע | 10MB | 512KB לאירועי Eventarc. 10MB לאירועים מדור קודם. |
לא | לכל אירוע |
נפח הזיכרון המקסימלי של פונקציה | נפח הזיכרון שכל מופע של פונקציה יכול להשתמש בו | 8GiB | 32GiB | לא | לכל פונקציה |
נפח הזיכרון המקסימלי של הפרויקט | נפח הזיכרון, ב-By, שפרויקט יכול להשתמש בו. המדד הזה נמדד לפי הסכום הכולל של הזיכרון שהמשתמשים ביקשו במופעי הפונקציה במהלך תקופה של דקה אחת. | תלוי באזור שנבחר. המגבלה הזו יכולה להיות גדולה יותר באזורים עם קיבולת גדולה, או נמוכה יותר באזורים שנפתחו לאחרונה. | לא רלוונטי | כן | לכל פרויקט ואזור |
מעבד (CPU) מקסימלי לפרויקט | כמות ה-CPU, במיליוני vCPU, שפרויקט יכול להשתמש בה. המדד הזה נמדד לפי הסכום הכולל של הבקשות של משתמשים לשימוש ב-CPU במופעי פונקציות במהלך תקופה של דקה אחת. | תלוי באזור שנבחר. המגבלה הזו יכולה להיות גדולה יותר באזורים עם קיבולת גדולה, או נמוכה יותר באזורים שנפתחו לאחרונה. | לא רלוונטי | כן | לכל פרויקט ואזור |
מגבלות זמן
מכסה | תיאור | Limit (דור ראשון) | Limit (דור שני) | אפשר להגדיל | היקף |
---|---|---|---|---|---|
משך הזמן המקסימלי של הפונקציה | משך הזמן המקסימלי שבו פונקציה יכולה לפעול לפני שהיא תופסק בכוח | 540 שניות | 60 דקות לפונקציות HTTP. 9 דקות לפונקציות מבוססות-אירוע. |
לא | לכל הפעלה |
הגבלות קצב
מכסה | תיאור | Limit (דור ראשון) | Limit (דור שני) | אפשר להגדיל | היקף |
---|---|---|---|---|---|
קריאות ל-API (קריאה) | קריאות לתיאור או לרישום של פונקציות באמצעות Cloud Functions API | 5,000 לכל 100 שניות | 1,200 לכל 60 שניות | רק לדור הראשון | לכל פרויקט (דור ראשון) לכל אזור (דור שני) |
קריאות ל-API (כתיבה) | קריאות לפריסה או למחיקה של פונקציות דרך Cloud Functions API | 80 לכל 100 שניות | 60 לכל 60 שניות | לא 1 | לכל פרויקט (דור ראשון) לכל אזור (דור שני) |
קריאות ל-API (CALL) | קריאות ל-API call | 16 לכל 100 שניות | לא רלוונטי | לא 2 | לכל פרויקט |
יכולת התאמה
פונקציות Cloud Functions שמופעלות על ידי HTTP עוברות התאמה לעומס במהירות כדי לטפל בתעבורה הנכנסת, ואילו פונקציות ברקע עוברות התאמה לעומס באופן הדרגתי יותר. היכולת של פונקציה להתאמה לעומס נקבע על סמך כמה גורמים, כולל:
- משך הזמן שלוקח להפעלת הפונקציה להסתיים (פונקציות קצרות בדרך כלל יכולות להתרחב כדי לטפל בבקשות בו-זמניות יותר).
- משך הזמן שלוקח לפונקציה להתאפס בהפעלה במצב התחלתי (cold start).
- שיעור השגיאות בפונקציה.
גורמים זמניים, כמו עומס אזורי וקיבולת של מרכז נתונים.
מכסות נוספות לפונקציות ברקע
מכסה | תיאור | מגבלה | אפשר להגדיל | היקף | גרסת המוצר |
---|---|---|---|---|---|
מספר מקסימלי של הפעלות בו-זמנית | מספר ההפעלות המקסימלי בו-זמנית של פונקציה אחת דוגמה: אם הטיפול בכל אירוע נמשך 100 שניות, קצב ההפעלה יוגבל ל-30 שניות בממוצע. |
3,000 | כן | לכל פונקציה | דור ראשון בלבד |
קצב ההפעלה המקסימלי | הקצב המקסימלי של אירועים שמטופלים על ידי פונקציה אחת דוגמה: אם טיפול באירוע נמשך 100 אלפיות השנייה, קצב ההפעלה יהיה מוגבל ל-1,000 פעולות לשנייה, גם אם רק 100 בקשות מטופלות במקביל בממוצע |
1,000 לשנייה | לא | לכל פונקציה | דור ראשון בלבד |
הגודל המקסימלי של נתוני אירועים בו-זמנית | הגודל הכולל המקסימלי של אירועים נכנסים להפעלות בו-זמנית של
פונקציה אחת דוגמה: אם אירועים הם בגודל 1MB והעיבוד שלהם נמשך 10 שניות, הקצב הממוצע יהיה אירוע אחד בשנייה, כי האירוע ה-11 לא יעובד עד לסיום העיבוד של אחד מ-10 האירועים הראשונים |
10MB | לא | לכל פונקציה | דור ראשון ודור שני |
קצב העברת הנתונים המקסימלי של אירועים נכנסים | קצב העברת הנתונים המקסימלי של אירועים נכנסים לפונקציה אחת דוגמה: אם האירועים הם בגודל 1MB, קצב ההפעלה יכול להיות לכל היותר 10 פעולות לשנייה, גם אם הפונקציות מסתיימות תוך 100ms |
10MB לשנייה | לא | לכל פונקציה | דור ראשון ודור שני |
כשמגיעים למכסה המקסימלית
כשפונקציה צורכת את כל המשאב שהוקצה לה, המשאב לא יהיה זמין עד שהמכסה תתעדכן או תגדל. כתוצאה מכך, ייתכן שהפונקציה וכל שאר הפונקציות באותו פרויקט לא יפעלו עד אז. פונקציה מחזירה קוד שגיאה HTTP 500 כשאחד המשאבים חורג מהמכסה והפונקציה לא יכולה לפעול.
כדי להגדיל את המכסות מעבר לברירת המחדל שמפורטת כאן, עוברים אל דף המכסות של Cloud Functions, בוחרים את המכסות שרוצים לשנות, לוחצים על EDIT QUOTAS (עריכת המכסות), מספקים את פרטי המשתמש אם מוצגת בקשה כזו ומזינים את מגבלת המכסה החדשה לכל מכסה שבחרתם.
מגבלות המכסות לפריסה של Firebase CLI
לכל פונקציה ש-Firebase CLI פורס, יש השפעה על סוגי המגבלות הבאים:
- קריאות ל-API (קריאה לקריאה) – קריאה אחת לכל פריסה, ללא קשר למספר הפונקציות
- מגבלה: 5,000 לכל 100 שניות
- קריאות ל-API (כתיבה) – קריאה אחת לכל פונקציה
- מגבלה: 80 פעולות לכל 100 שניות
אפשר לעיין גם במאמרי העזרה של Firebase CLI.