Catch up on everything announced at Firebase Summit, and learn how Firebase can help you accelerate app development and run your app with confidence. Learn More

Quoten und Limits

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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, und/oder die Rate, mit der Ressourcen verwendet werden können. Sie können sich Ratenkontingente als „Ressourcen im Laufe der Zeit“ vorstellen.

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

Ressourcengrenzen 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 Zielfernrohr
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 10 MB 32 MB Nein pro Aufruf
Maximale unkomprimierte HTTP-Antwortgröße Daten, die von HTTP-Funktionen in einer HTTP-Antwort gesendet werden 10MB 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 Zielfernrohr
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 Zielfernrohr
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
  • Ratenbegrenzungen , wie oben beschrieben.
  • Die Fehlerrate Ihrer Funktion.
  • Vorübergehende Faktoren wie regionale Auslastung und Rechenzentrumskapazität.
Hintergrundfunktionen haben zusätzliche Beschränkungen, wie unten erläutert. Diese Beschränkungen gelten nicht für HTTP-Funktionen .

Zusätzliche Kontingente für Hintergrundfunktionen

Quote Beschreibung Grenze Kann erhöht werden Zielfernrohr
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
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
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
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

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 .