Auf dieser Seite werden die skalierbaren, nutzungsbasierten Limits für Cloud-Funktionen gemäß dem nutzungsabhängigen Preisplan von Blaze beschrieben. Diese Beschränkungen 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 geringfügige Gebühren für den Speicherplatz an, der für den Container der Funktion verwendet wird. Weitere Informationen finden Sie in den häufig gestellten Fragen zu Firebase.
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 die Dinge laufen können.
Ratenbegrenzungen
Diese wirken sich auf die Rate aus, mit der Sie die Cloud Functions API aufrufen können, um Ihre Funktionen zu verwalten.
Die verschiedenen Arten von Limits werden im Folgenden näher beschrieben. Auf Unterschiede zwischen den Limits für Cloud Functions (1. Generation) und Cloud Functions (2. Generation) wird gegebenenfalls hingewiesen.
Ressourcengrenzen
Ressourcenlimits 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 bei.
| Quote | Beschreibung | Grenze (1. Generation) | Grenze (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 abzüglich 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-Anforderungsgröße | Daten, die in einer HTTP-Anforderung an HTTP-Funktionen gesendet werden | 10MB | 32MB | NEIN | pro Aufruf |
| Maximale unkomprimierte HTTP-Antwortgröße | Daten, die von HTTP-Funktionen in einer HTTP-Antwort gesendet werden | 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 | 10MB | 512 KB für Eventarc-Ereignisse. 10 MB für Legacy-Ereignisse. | NEIN | pro Veranstaltung |
| Maximaler Funktionsspeicher | Speichermenge, die jede Funktionsinstanz verwenden kann | 8 GB | 16 GB | NEIN | pro Funktion |
Zeitbegrenzungen
| Quote | Beschreibung | Grenze (1. Generation) | Grenze (2. Generation) | Kann erhöht werden | Umfang |
|---|---|---|---|---|---|
| Max. Funktionsdauer | Die maximale Zeit, die eine Funktion ausgeführt werden kann, bevor sie zwangsweise beendet wird | 540 Sekunden | 60 Minuten für HTTP-Funktionen. 10 Minuten für ereignisgesteuerte Funktionen. | NEIN | pro Aufruf |
Ratenbegrenzungen
| Quote | Beschreibung | Grenze (1. Generation) | Grenze (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 1. Gen | 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 | Nein 1 | pro Projekt (1. Generation) pro Region (2. Generation) |
| API-Aufrufe (CALL) | Aufrufe der „call“-API | 16 pro 100 Sekunden | N / A | Nein 2 | pro Projekt |
Skalierbarkeit
Über HTTP aufgerufene Cloud-Funktionen werden schnell hochskaliert, um eingehenden Datenverkehr zu verarbeiten, während Hintergrundfunktionen langsamer skaliert werden. Die Fähigkeit einer Funktion zum Hochskalieren wird von einigen Faktoren bestimmt, darunter:
- Die Zeit, die für die Ausführung einer Funktion benötigt wird (kurz laufende Funktionen können im Allgemeinen hochskaliert 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, wird die Aufrufrate auf durchschnittlich 30 pro Sekunde begrenzt | 3.000 | NEIN | pro Funktion | Nur 1. Generation |
| Maximale Aufrufrate | Die maximale Rate von Ereignissen, die von einer einzelnen Funktion verarbeitet werden Beispiel: Wenn die Bearbeitung eines Ereignisses 100 ms dauert, wird 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 für gleichzeitige Ereignisse | Die maximale Gesamtgröße eingehender Ereignisse für gleichzeitige Aufrufe 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 nicht verarbeitet wird, bis die Verarbeitung eines der ersten 10 Ereignisse abgeschlossen ist | 10MB | NEIN | pro Funktion | 1. Gen. und 2. Gen |
| Maximaler Durchsatz eingehender Ereignisse | Der maximale Durchsatz eingehender Ereignisse für eine einzelne Funktion Beispiel: Wenn Ereignisse eine Größe von 1 MB haben, kann die Aufrufrate maximal 10 pro Sekunde betragen, selbst wenn Funktionen innerhalb von 100 ms beendet werden | 10 MB pro Sekunde | NEIN | pro Funktion | 1. Gen. und 2. Gen |
Wenn Sie ein Kontingentlimit erreichen
Wenn eine Funktion die gesamte zugewiesene Ressource verbraucht, wird 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 QUOTEN BEARBEITEN , geben Sie Ihre Benutzerinformationen ein, wenn Sie dazu aufgefordert werden, und geben Sie das neue Kontingentlimit für jedes ausgewählte Kontingent ein.
Kontingentlimits für die Firebase CLI-Bereitstellung
Für jede Funktion, die die Firebase CLI bereitstellt, sind diese Arten von Raten- und Zeitlimits betroffen:
- API-Aufrufe (READ) – 1 Aufruf pro Bereitstellung, egal wie viele Funktionen
- Limit: 5000 pro 100 Sekunden
- API-Aufrufe (WRITE) - 1 Aufruf pro Funktion
- Limit: 80 pro 100 Sekunden
Siehe auch die Firebase-CLI-Referenz .