Auf dieser Seite werden die skalierbaren, nutzungsbasierten Limits für Cloud Functions gemäß dem Blaze-Pay-as-you-go-Preisplan detailliert beschrieben. Diese Grenzwerte gelten für Firebase-Projekte, die Funktionen in der Node.js 10-Laufzeitumgebung bereitstellen.
Der Blaze-Plan bietet großzügige Mengen an Aufrufen, Rechenzeit und Internetverkehr kostenlos. Bei Funktionsbereitstellungen fallen jedoch geringe Gebühren für den Speicherplatz an, der für den Funktionscontainer verwendet wird. Weitere Informationen finden Sie in den Firebase- FAQ .
Kontingente für Google Cloud Functions umfassen drei Bereiche:
Ressourcengrenzen
Diese wirken sich auf die Gesamtmenge an Ressourcen aus, die Ihre Funktionen verbrauchen können.
Zeitbegrenzungen
Diese beeinflussen, wie lange Dinge laufen können.
Ratenbeschränkungen
Diese wirken sich auf die Geschwindigkeit aus, mit der Sie die Cloud Functions-API aufrufen können, um Ihre Funktionen zu verwalten.
Im Folgenden werden die verschiedenen Arten von Limits näher beschrieben. Auf Unterschiede zwischen den Grenzwerten für Cloud Functions (1. Generation) und Cloud Functions (2. Generation) wird gegebenenfalls hingewiesen.
Ressourcengrenzen
Ressourcenbeschränkungen wirken sich auf die Gesamtmenge an Ressourcen aus, die Ihre Funktionen verbrauchen können. Der regionale Geltungsbereich gilt pro Projekt, und jedes Projekt behält seine eigenen Grenzen.
| Quote | Beschreibung | Limit (1. Generation) | Limit (2. Generation) | Kann erhöht werden | Umfang |
|---|---|---|---|---|---|
| Anzahl der Funktionen | Die Gesamtzahl der Funktionen, die pro Region bereitgestellt werden können | 1.000 | 1.000 minus der Anzahl der bereitgestellten Cloud Run-Dienste | NEIN | pro Region |
| Maximale Bereitstellungsgröße | Die maximale Größe einer einzelnen Funktionsbereitstellung | 100 MB (komprimiert) für Quellen. 500 MB (unkomprimiert) für Quellen plus Module. | N / A | NEIN | pro Funktion |
| Maximale unkomprimierte HTTP-Anfragegröße | Daten, die in einer HTTP-Anfrage an HTTP-Funktionen gesendet werden | 10 MB | 32 MB | NEIN | pro Aufruf |
| Maximale unkomprimierte HTTP-Antwortgröße | Von HTTP-Funktionen in einer HTTP-Antwort gesendete Daten | 10 MB | 10 MB für Streaming-Antworten. 32 MB für Nicht-Streaming-Antworten. | NEIN | pro Aufruf |
| Maximale Ereignisgröße für ereignisgesteuerte Funktionen | Daten, die in Ereignissen an Hintergrundfunktionen gesendet werden | 10 MB | 512 KB für Eventarc-Events. 10 MB für Legacy-Events. | NEIN | pro Veranstaltung |
| Maximaler Funktionsspeicher | Speichermenge, die jede Funktionsinstanz nutzen kann | 8 GB | 32 GB | NEIN | pro Funktion |
Zeitbegrenzungen
| Quote | Beschreibung | Limit (1. Generation) | Limit (2. Generation) | Kann erhöht werden | Umfang |
|---|---|---|---|---|---|
| Maximale Funktionsdauer | Die maximale Zeitspanne, die eine Funktion ausgeführt werden kann, bevor sie zwangsweise beendet wird | 540 Sekunden | 60 Minuten für HTTP-Funktionen. 9 Minuten für ereignisgesteuerte Funktionen. | NEIN | pro Aufruf |
Ratenbeschränkungen
| Quote | Beschreibung | Limit (1. Generation) | Limit (2. Generation) | Kann erhöht werden | Umfang |
|---|---|---|---|---|---|
| API-Aufrufe (READ) | Aufrufe zum Beschreiben oder Auflisten von Funktionen über die Cloud Functions API | 5000 pro 100 Sekunden | 1200 pro 60 Sekunden | Nur für die 1. Generation | pro Projekt (1. Generation) pro Region (2. Generation) |
| API-Aufrufe (WRITE) | Aufrufe zum Bereitstellen oder Löschen von Funktionen über die Cloud Functions API | 80 pro 100 Sekunden | 60 pro 60 Sekunden | Nr. 1 | pro Projekt (1. Generation) pro Region (2. Generation) |
| API-Aufrufe (CALL) | Aufrufe der „call“-API | 16 pro 100 Sekunden | N / A | Nr. 2 | pro Projekt |
Skalierbarkeit
Über HTTP aufgerufene Cloud-Funktionen werden schnell skaliert, um eingehenden Datenverkehr zu verarbeiten, während Hintergrundfunktionen langsamer skaliert werden. Die Skalierungsfähigkeit einer Funktion wird von einigen Faktoren bestimmt, darunter:
- Die Zeit, die es dauert, bis die Ausführung einer Funktion abgeschlossen ist (kurz laufende Funktionen können im Allgemeinen skaliert werden, um mehr gleichzeitige Anforderungen zu verarbeiten).
- Die Zeit, die eine Funktion benötigt, um beim Kaltstart zu initialisieren.
- Die Fehlerrate Ihrer Funktion.
Vorübergehende Faktoren wie regionale Auslastung und Rechenzentrumskapazität.
Zusätzliche Kontingente für Hintergrundfunktionen
| Quote | Beschreibung | Grenze | Kann erhöht werden | Umfang | Produktversion |
|---|---|---|---|---|---|
| Max. gleichzeitige Aufrufe | Die maximale Anzahl gleichzeitiger Aufrufe einer einzelnen Funktion Beispiel: Wenn die Bearbeitung jedes Ereignisses 100 Sekunden dauert, ist die Aufrufrate auf durchschnittlich 30 pro Sekunde begrenzt | 3.000 | Ja | pro Funktion | Nur 1. Generation |
| Maximale Aufrufrate | Die maximale Ereignisrate, die von einer einzelnen Funktion verarbeitet wird Beispiel: Wenn die Bearbeitung eines Ereignisses 100 ms dauert, ist die Aufrufrate auf 1000 pro Sekunde begrenzt, selbst wenn im Durchschnitt nur 100 Anfragen parallel bearbeitet werden | 1000 pro Sekunde | NEIN | pro Funktion | Nur 1. Generation |
| Maximale Datengröße gleichzeitiger Ereignisse | Die maximale Gesamtgröße eingehender Ereignisse bei gleichzeitigen Aufrufen einer einzelnen Funktion Beispiel: Wenn Ereignisse eine Größe von 1 MB haben und ihre Verarbeitung 10 Sekunden dauert, beträgt die durchschnittliche Rate 1 Ereignis pro Sekunde, da das 11. Ereignis erst verarbeitet wird, wenn die Verarbeitung eines der ersten 10 Ereignisse abgeschlossen ist | 10 MB | NEIN | pro Funktion | 1. Generation und 2. Generation |
| Maximaler Durchsatz eingehender Ereignisse | Der maximale Durchsatz eingehender Ereignisse an eine einzelne Funktion Beispiel: Wenn Ereignisse eine Größe von 1 MB haben, kann die Aufrufrate maximal 10 pro Sekunde betragen, selbst wenn die Funktionen innerhalb von 100 ms abgeschlossen werden | 10 MB pro Sekunde | NEIN | pro Funktion | 1. Generation und 2. Generation |
Wenn Sie ein Kontingentlimit erreichen
Wenn eine Funktion die gesamte zugewiesene Ressource verbraucht, ist die Ressource nicht verfügbar, bis das Kontingent aktualisiert oder erhöht wird. Dies kann dazu führen, dass Ihre Funktion und alle anderen Funktionen im selben Projekt bis dahin nicht funktionieren. Eine Funktion gibt einen HTTP-500-Fehlercode zurück, wenn eine der Ressourcen das Kontingent überschreitet und die Funktion nicht ausgeführt werden kann.
Um die Kontingente über die hier aufgeführten Standardwerte hinaus zu erhöhen, gehen Sie zur Cloud Functions-Kontingentseite , wählen Sie die Kontingente aus, die Sie ändern möchten, klicken Sie auf QUOTAS BEARBEITEN , geben Sie bei Aufforderung Ihre Benutzerinformationen ein und geben Sie das neue Kontingentlimit für jedes ausgewählte Kontingent ein.
Kontingentgrenzen für die Firebase-CLI-Bereitstellung
Für jede Funktion, die die Firebase-CLI bereitstellt, sind folgende Arten von Raten- und Zeitlimits betroffen:
- API-Aufrufe (READ) – 1 Aufruf pro Bereitstellung, unabhängig von der Anzahl der Funktionen
- Limit: 5000 pro 100 Sekunden
- API-Aufrufe (WRITE) – 1 Aufruf pro Funktion
- Limit: 80 pro 100 Sekunden
Siehe auch die Firebase-CLI-Referenz .