Kontingente

In diesem Dokument werden die Kontingentlimits für Cloud Run Functions beschrieben.

Auf der Seite „Kontingente“ in Cloud Run Functions können Sie Kontingente über die hier aufgeführten Standardwerte hinaus erhöhen. Wählen Sie dazu die Kontingente aus, die Sie ändern möchten, klicken Sie auf Kontingente bearbeiten, geben Sie Ihre Nutzerdaten an, wenn Sie dazu aufgefordert werden, und legen Sie die neuen Limits für die ausgewählten Kontingente fest.

Kontingente für Cloud Run Functions umfassen vier Bereiche:

• Ressourcenlimits

  Diese beeinflussen die Gesamtmenge der Ressourcen, die Ihre Funktionen verbrauchen können.

• Zeitlimits

  Diese beeinflussen die maximale Ausführungsdauer der einzelnen Funktionen.

• Ratenlimits

  Diese beeinflussen die Rate, mit der Sie die Cloud Run Functions API aufrufen können, um Ihre Funktionen zu verwalten.

• Netzwerklimits

  Sie wirken sich auf die Limits für ausgehende Verbindungen und Instanzen aus.

Die verschiedenen Arten von Limits werden im Folgenden näher beschrieben. Die Unterschiede zwischen den Limits für Cloud Run-Funktionen (1. Generation) und Cloud Run-Funktionen (2. Generation) werden gegebenenfalls aufgeführt.

Ressourcenlimits

Ressourcenlimits beeinflussen die Gesamtmenge der Ressourcen, die Ihre Funktionen verbrauchen können. Der regionale Bereich gilt pro Projekt und jedes Projekt hat seine eigenen Limits.

Kontingent	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 die Anzahl der bereitgestellten Cloud Run-Dienste	Nein	pro Region
Max. Bereitstellungsgröße	Die maximale Größe einer einzelnen Funktionsbereitstellung	100 MB (komprimiert) für Quellen 500 MB (unkomprimiert) für Quellen und Module	–	Nein	pro Funktion
Max. unkomprimierte Größe einer HTTP-Anfrage	Daten, die an HTTP-Funktionen in einer HTTP-Anfrage gesendet werden	10 MB	32 MB	Nein	pro Aufruf
Max. unkomprimierte Größe einer HTTP-Antwort	Daten, die von HTTP-Funktionen in einer HTTP-Antwort gesendet werden	10 MB	10 MB für Streamingantworten. 32 MB für Antworten ohne Streaming.	Nein	pro Aufruf
Max. Ereignisgröße für ereignisgesteuerte Funktionen	Daten, die in Ereignissen an Hintergrundfunktionen gesendet werden	10 MB	512 KB für Eventarc-Ereignisse 10 MB für Legacy-Ereignisse.	Nein	pro Ereignis
Max. Funktionsspeicher	Größe des Arbeitsspeichers, den jede Funktionsinstanz verwenden kann	8 GiB	32 GiB	Nein	pro Funktion
Max. Projektspeicher	Speicherplatz in By, den ein Projekt nutzen kann. Er wird anhand der Gesamtsumme des vom Nutzer angeforderten Arbeitsspeichers in allen Funktionsinstanzen über einen Zeitraum von einer Minute gemessen.	Hängt von der ausgewählten Region ab. Dieses Limit kann in Regionen mit hoher Kapazität höher oder in kürzlich geöffneten Regionen niedriger sein.	–	Ja	pro Projekt und Region
Max. CPU-Auslastung des Projekts	Die CPU-Kapazität in Milli-vCPUs, die ein Projekt nutzen kann. Er wird anhand der Gesamtsumme der vom Nutzer angeforderten CPU-Zeit über alle Funktionsinstanzen hinweg in einem Zeitraum von einer Minute gemessen.	Hängt von der ausgewählten Region ab. Dieses Limit kann in Regionen mit hoher Kapazität höher oder in kürzlich geöffneten Regionen niedriger sein.	–	Ja	pro Projekt und Region

Hinweis: Wenn Sie eine Funktion mit Pub/Sub auslösen, entweder über ereignisgesteuerte Funktionen oder als HTTP-Ziel eines Push-Abos, beachten Sie, dass Pub/Sub-Nachrichten base64-codiert sind. Eine 10 MB große Pub/Sub-Nachricht - die unterstützte maximale Größe ist nach der Codierung größer als 10 MB und kann somit die maximale Größe von Cloud Run Functions überschreiten.

Zeitlimits

Kontingent	Beschreibung	Limit (1. Generation)	Limit (2. Generation)	Kann erhöht werden	Umfang
Max. Funktionsdauer	Der maximale Zeitraum, über den eine Funktion ausgeführt werden kann, bevor sie zwangsweise beendet wird.	540 Sekunden	60 Minuten für HTTP-Funktionen. 9 minutes for event-driven functions.	Nein	pro Aufruf

Ratenlimits

Kontingent	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 Run Functions API.	5.000 pro 100 Sekunden	1.200 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 Run Functions API.	80 pro 100 Sekunden	60 pro 60 Sekunden	Nein ^1	pro Projekt (1. Generation) pro Region (2. Generation)
API-Aufrufe (CALL)	Aufrufe an die API „call“.	16 pro 100 Sekunden	–	Nein ^2	pro Projekt

¹ Sie können das WRITE-Kontingent nicht erhöhen. Ein unzureichendes Kontingent tritt im Allgemeinen aus einem der folgenden Gründe auf:

• Verwendung eines CI-/CD-Systems, das viele Funktionen gleichzeitig oder nacheinander mit hoher Geschwindigkeit bereitstellt
• Verwendung der Firebase CLI für die gleichzeitige Bereitstellung mehrerer Funktionen

Sie können es in jedem Fall vermeiden, diese Kontingente auszuschöpfen, indem Sie die Bereitstellungsrate ändern. Wenn Sie beispielsweise Bereitstellungen mit der Firebase CLI vornehmen, verwenden Sie das Flag --only, um einzelne Funktionen bereitzustellen.

² Die CALL API gilt nur für Cloud Run-Funktionen (1. Generation). Sie können das CALL-Kontingent nicht erhöhen. Ein unzureichendes Kontingent tritt im Allgemeinen auf, wenn Sie diese API fälschlicherweise zum Aufrufen von Funktionen in der Produktion verwenden. Bitte beachten Sie, dass diese API für Tests über die Google Cloud Console oder die gcloud functions call-CLI vorgesehen ist und keinen starken Traffic bewältigen kann.

Netzwerklimits

Informationen zu den Limits für Netzwerkanfragen und Bandbreiten von Cloud Run-Funktionen (2. Generation) finden Sie unter Netzwerklimits.

Für Cloud Run Functions (1. Generation) gelten die folgenden Netzwerklimits:

• Ausgehende Verbindungen pro Sekunde und Instanz: 500 (kann nicht erhöht werden)
• Ausgehende DNS-Auflösungen pro Sekunde und Instanz: 100 (kann nicht erhöht werden)

Skalierbarkeit

Funktionen von Cloud Run Functions, die über HTTP aufgerufen werden, lassen sich schnell für die Verarbeitung von eingehendem Traffic skalieren, während Hintergrundfunktionen mehr schrittweise skaliert werden. Die Fähigkeit einer Funktion zum Hochskalieren wird von einigen Faktoren bestimmt, darunter:

• Die Ausführungsdauer einer Funktion (Funktionen mit kurzer Ausführungsdauer lassen sich im Allgemeinen für die Verarbeitung einer größeren Anzahl gleichzeitiger Anfragen hochskalieren).
• Die Zeit, die eine Funktion nach einem Kaltstart zur Initialisierung benötigt.
• Die Fehlerrate Ihrer Funktion.

• Vorübergehende Faktoren, wie z. B. die regionale Last oder die Rechenzentrumskapazität.

• Ihre Konfiguration, wie in Mindestanzahl von Instanzen, Maximale Anzahl von Instanzen und Gleichzeitigkeit (Gleichzeitigkeit ist 2. Generation) festgelegt.

Für Hintergrundfunktionen gelten die unten näher erläuterten zusätzlichen Limits. HTTP-Funktionen der 1. Generation sind davon nicht betroffen. Das standardmäßige Limit für die maximale Anzahl von Instanzen für HTTP-Funktionen der 2. Generation ist 100 und kann auf 1.000 erhöht werden. Für HTTP-Funktionen der 1. Generation gibt es kein Standardlimit für die maximale Anzahl von Instanzen. Zur Vermeidung unbegrenzter Skalierungsereignisse mit HTTP-Funktionen der 1. Generation empfehlen wir die Festlegung eines Limits, z. B. 3.000.

Zusätzliche Kontingente für Hintergrundfunktionen

Kontingent	Beschreibung	Limit	Kann erhöht werden	Umfang	Produktversion
Maximale Anzahl gleichzeitiger Aufrufe	Die maximale Anzahl gleichzeitiger Aufrufe einer einzelnen Funktion Beispiel: Wenn die Verarbeitung jedes Ereignisses 100 Sekunden dauert, ist die Aufrufrate im Durchschnitt auf 30 pro Sekunde begrenzt.	3.000	Ja	pro Funktion	Nur 1. Generation
Maximale Aufrufrate	Die maximale Rate von Ereignissen, die von einer einzelnen Funktion verarbeitet werden. Beispiel: Wenn die Verarbeitung jedes Ereignisses 100 ms dauert, ist die Aufrufrate auf 1.000 Aufrufe pro Sekunde begrenzt, auch wenn durchschnittlich nur 100 Anfragen gleichzeitig verarbeitet werden.	1.000 pro Sekunde	Nein	pro Funktion	Nur 1. Generation
Maximale Datengröße gleichzeitiger 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, liegt die Durchschnittsrate bei 1 Ereignis pro Sekunde, weil das 11. Ereignis nicht verarbeitet wird, bis die Verarbeitung von einem 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 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 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 eine zugeordnete Ressource vollständig verbraucht hat, ist sie erst nach einer Erneuerung bzw. Erweiterung des Kontingents wieder verfügbar. Dies kann bedeuten, dass diese sowie alle anderen Funktionen im selben Projekt bis dahin nicht funktionieren. Eine Funktion gibt den HTTP-Fehlercode 500 zurück, wenn eine der Ressourcen über dem Kontingent liegt und die Funktion daher nicht ausgeführt werden kann.

Auf der Seite „Kontingente“ in Cloud Run Functions können Sie Kontingente über die hier aufgeführten Standardwerte hinaus erhöhen. Wählen Sie dazu die Kontingente aus, die Sie ändern möchten, klicken Sie auf Kontingente bearbeiten, geben Sie Ihre Nutzerdaten an, wenn Sie dazu aufgefordert werden, und legen Sie die neuen Limits für die ausgewählten Kontingente fest.