In diesem Dokument sind die Kontingente und Limits aufgeführt, die für Workflows
Google Cloud nutzt Kontingente, um Fairness zu gewährleisten und Spitzen bei Ressourcennutzung und -verfügbarkeit zu reduzieren. Ein Kontingent schränkt ein, wie viel von einer Google Cloud-Ressource Ihr Google Cloud-Projekt nutzen darf. Kontingente gelten für eine Reihe von Ressourcentypen, einschließlich Hardware, Software und Netzwerkkomponenten. Mit Kontingenten können Sie beispielsweise die Anzahl der API-Aufrufe an einen Dienst, die Anzahl der von Ihrem Projekt gleichzeitig verwendeten Load Balancer oder die Anzahl der Projekte begrenzen, die Sie erstellen können. Die Kontingente sollen eine Überlastung von Diensten verhindern und dadurch die Community der Google Cloud-Nutzer schützen. Sie helfen Ihnen auch bei der Verwaltung Ihrer eigenen Google Cloud-Ressourcen.
Das Cloud-Kontingentsystem ermöglicht Folgendes:
- Ihren Verbrauch von Google Cloud-Produkten und -Diensten überwachen
- Ihren Verbrauch dieser Ressourcen einschränken
- Eine Möglichkeit bieten, Änderungen am Kontingentwert anzufordern
Wenn Sie versuchen, mehr von einer Ressource zu verbrauchen, als das Kontingent zulässt, blockiert das System in den meisten Fällen den Zugriff auf die Ressource. Die Aufgabe, die Sie ausführen möchten, schlägt fehl.
Kontingente gelten in der Regel auf Google Cloud-Projektebene. Ihre Nutzung einer Ressource in einem Projekt hat keinen Einfluss auf Ihr verfügbares Kontingent in einem anderen Projekt. Innerhalb eines Google Cloud-Projekts werden die Kontingente für alle Anwendungen und IP-Adressen gemeinsam genutzt.
Auch Limits für Workflows-Ressourcen gelten. Diese Limits stehen nicht im Zusammenhang mit dem Kontingentsystem. Limits können nur geändert werden, wenn etwas anderes angegeben ist.
Kontingente
Workflows erzwingt folgende Kontingente für jede Google Cloud Projekt arbeiten. Sie können diese Kontingente erhöhen oder verringern:
Kontingent | Beschreibung | Wert |
---|---|---|
Workflows insgesamt | Die maximale Anzahl von Workflows, die Sie pro Projekt bereitstellen können | 10.000 |
Gleichzeitige Ausführungen | Die maximale Anzahl aktiver Workflowausführungen pro Region und pro Projekt arbeiten. Gleichzeitige Ausführungen sind Ausführungen, die gestartet wurden und nicht die noch abgeschlossen sind oder fehlgeschlagen sind, einschließlich solcher, die noch auf Rückrufe oder die gerade schlafen. Sobald das Kontingent erreicht ist und
Ausführungsrückprotokoll aktiviert ist, Ausführungen werden in
hat den Status |
10.000 |
Zurückgestellte Ausführungen | Die maximale Anzahl der im Rückstand befindlichen Workflowausführungen pro Region und pro
Projekt arbeiten.
Weitere Informationen finden Sie unter Ausführungsrückprotokoll verwalten |
100.000 |
Workflow API-Anfragen | Die maximale Anzahl von API-Anfragen (create ,
update , list , get
delete ) aus allen Workflows in Ihrem Projekt
(pro Minute und Standort) |
1.200 |
Execution API-Get-Anfragen | Die maximale Anzahl von Anfragen an get -Workflowausführungen aus allen Workflows in Ihrem Projekt (pro Minute und Standort) |
6.000 |
Execution API-List-Anfragen | Die maximale Anzahl von Anfragen an Workflowausführungen von list aus allen Workflows in Ihrem Projekt (pro Minute und Standort) |
1.200 |
Execution API-Schreibanfragen | Die maximale Anzahl von Anfragen an
create
und
cancel
Workflowausführungen (einschließlich durch Eventarc ausgelöste
Ausführungen) aus allen Workflows in Ihrem Projekt (pro Minute und
Standort).
Wenn durch Eventarc ausgelöste Ausführungen diesen Höchstwert überschreiten, -Ereignisse werden nach dem Eventarc-Wiederholungsrichtlinie. |
6.000 |
Anfragen zum Abrufen von Schritteinträgen der Execution API | Die maximale Anzahl von Anfragen an
get
ein Schritteintrag aus einer Workflowausführung (pro Minute und Standort) |
6.000 |
Anfragen für Listenschritteinträge der Execution API | Die maximale Anzahl von Anfragen an
list
Schritteinträge aus einer Workflowausführung (pro Minute und Standort) |
1.200 |
Execution API-Datenexportanfragen | Die maximale Anzahl von Anfragen an
export data
aus einer Workflowausführung (pro Minute und Standort) |
10 |
HTTP-Anfragen an Callback-Endpunkte | Die maximale Anzahl von SendHttpCallback API-Anfragen
für Ausführungsressourcen aus allen Workflows in Ihrem Projekt (pro Minute)
pro Standort) |
1.500 |
Callback-Anfragen für Liste der Execution API | Die maximale Anzahl von list -Callbacks pro Minute und Standort, die bei einer Workflowausführung gesendet werden |
300 |
Anfragen zur Kontingenterhöhung
Verwenden Sie die Google Cloud Console, um Kontingente zu erhöhen oder zu verringern. Weitere Informationen Weitere Informationen finden Sie unter Höheres Kontingent anfordern.
Schrittlimits
Workflows erzwingen die folgenden Schrittlimits für jeden Workflow. Sie können an diesen Limits keine Änderungen anfordern:
Limit | Beschreibung | Wert |
---|---|---|
Aufgaben pro Schritt | Die maximale Anzahl von Aufgaben die in einem einzigen Schritt durchgeführt werden kann, | 50 |
Bedingungen pro Schalter | Die maximale Anzahl an Bedingungen, die in einem einzelnen Schalterblock | 50 |
Maximale Aufrufstack-Tiefe | Die maximale Anzahl der Ebenen von aufrufenden Funktionen. Wenn beispielsweise ein sich selbst oder einen anderen untergeordneten Workflow aufruft. Standardbibliothek Funktionsaufrufe, die wiederum andere Funktionen aufrufen | 20 |
Mindestanzahl von Schritten | Mindestanzahl von Schritten in einem Workflow | 1 |
Maximale Anzahl der Schritte | Die maximale Anzahl von Schritten, die in einer einzelnen Workflowausführung ausgeführt werden können | 100.000 |
Limits für parallele Schritte
Workflows erzwingen bei der Verwendung paralleler Schritte die folgenden Limits. Sie können an diesen Limits keine Änderungen anfordern:
Limit | Beschreibung | Wert |
---|---|---|
Zweige pro Schritt | Die maximale Anzahl von Zweigen, die in einem paralleler Schritt | 10 |
Parallele Tiefe | Die maximale Tiefe, die parallele Schritte verschachtelt werden können | 2 |
Gleichzeitige Zweige und Iterationen | Die maximale Anzahl von Zweigen und Iterationen, die gleichzeitig ausgeführt werden können innerhalb einer einzelnen Workflowausführung vor weiteren Zweigen und Iterationen werden automatisch in die Warteschlange gestellt, um auf eine oder mehrere Ausführungen zu warten Threads zu beenden. Es gibt keine Obergrenze für die Gesamtzahl der Threads. Es gelten jedoch alle anderen Limits. |
20 |
Nicht abgefangene Ausnahmen in einem parallelen Schritt | Die maximale Anzahl unbehandelter Ausnahmen, die während die Ausführung des Workflows (insgesamt) | 100 |
Ressourcenlimits
Für Workflows gelten die folgenden Nutzungslimits. Sie können keine Änderungen an diesen Limits:
Limit | Beschreibung | Wert |
---|---|---|
Größe des Quellcodes | Die maximale Größe der YAML- oder JSON-Datei, mit der Ihr Workflow definiert wird. | 128 KB |
Größe der Antwort | Die maximale Größe einer HTTP-Antwort (bei Speicherung in einer Variablen für Variablen gilt) | 2 MB |
Ausdruckslänge | Die maximale Anzahl von Zeichen in einem einzelnen Ausdruck | 400 Zeichen |
Datengröße | Die maximale kumulative Größe für Variablen, Argumente und Ereignisse: | 512 KB |
|
||
|
||
|
||
Maximaler string Länge in Byte mit UTF-8-Codierung | 256 KB | |
Umgebungsvariablen | Die maximale Größe für
Definitionsstring für benutzerdefinierte Umgebungsvariable
(KEY=value ); können maximal 20 Variablen definiert werden |
4 KiB |
Dauer der Ausführung | Die maximale Dauer eines Workflows (von Start bis Ende) execution; Jeder Workflow, bei dem dieses Limit überschritten wird, endet mit einer Zeitüberschreitung. Fehler | 1 Jahr |
Ausführungsaufbewahrung | Die maximale Aufbewahrungsdauer (nach Abschluss einer Workflowausführung) des Verlaufs und der Ergebnisse einer Ausführung | 90 Tage |
Zeitfenster für Deduplizierung | Das Deduplizierungsfenster, um eine genau einmalige Verarbeitung zu gewährleisten, eine Workflow-Ausführung mit Ereignisse | 24 Stunden |