Kontingente und Limits

Workflows verwendet Kontingente und Systemlimits, um eine faire Ressourcenzuweisung zu gewährleisten, Dienstüberlastungen zu verhindern und Sie bei der Verwaltung der Ressourcennutzung zu unterstützen.

Kontingente und Systemlimits sind ähnlich, unterscheiden sich aber in folgenden Punkten:

  • Kontingente haben Standardwerte, aber Sie können in der Regel Anpassungen anfordern.
  • Systemlimits sind feste Werte, die nicht geändert werden können.

Google Cloud nutzt Kontingente, um für Fairness zu sorgen und Spitzen bei der Ressourcennutzung und ‑verfügbarkeit zu reduzieren. Ein Kontingent schränkt ein, wie viel von einerGoogle Cloud Ressource Ihr Google Cloud Projekt nutzen kann. 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 nebenläufig verwendeten Load Balancer oder die Anzahl der Projekte begrenzen, die Sie erstellen können. Kontingente sollen eine Überlastung von Diensten verhindern und dadurch die Community derGoogle Cloud Nutzer schützen. Sie helfen Ihnen auch bei der Verwaltung Ihrer eigenen Google Cloud Ressourcen.

Das Cloud-Kontingentsystem tut Folgendes:

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 auszuführen versuchen, schlägt dann fehl.

Kontingente gelten in der Regel auf Google Cloud Projektebene. Die Nutzung einer Ressource in einem Projekt hat keinen Einfluss auf das verfügbare Kontingent in einem anderen Projekt. Innerhalb eines Google Cloud Projekts werden die Kontingente für alle Anwendungen und IP-Adressen gemeinsam genutzt.

Weitere Informationen finden Sie unter Cloud-Kontingente – Übersicht.

Für Workflows-Ressourcen gelten außerdem Systemlimits. Systemlimits können nicht geändert werden.

Kontingente

Workflows erzwingt die folgenden Kontingente für jedes Google Cloud-Projekt. 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 Projekt. Gleichzeitige Ausführungen sind Ausführungen, die gestartet, aber noch nicht abgeschlossen wurden oder fehlgeschlagen sind, einschließlich aller Ausführungen, die auf Callbacks warten oder sich im Ruhezustand befinden.

Sobald das Kontingent erreicht ist und das Backlogging für Ausführungen standardmäßig aktiviert ist (mit einigen Ausnahmen), werden Ausführungen im Status QUEUED erstellt. Wenn der Backlog für Ausführungen deaktiviert ist oder das Kontingent für Backlog-Ausführungen erreicht ist, schlagen alle neuen Ausführungen mit dem HTTP-Statuscode 429 Too many requests fehl. Weitere Informationen finden Sie unter Ausführungs-Backlogging verwalten.

 10.000
Ausführungen im Rückstand Die maximale Anzahl von Workflowausführungen im Rückstand pro Region und Projekt.

Weitere Informationen finden Sie unter Ausführungs-Backlog verwalten.

 100.000
Workflow API-Anfragen Die maximale Anzahl von API-Anfragen (create, update, list, get, delete) von 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 list-Workflowausführungen 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 Eventarc-getriggerter Ausführungen) von allen Workflows in Ihrem Projekt (pro Minute und Standort).

Wenn Eventarc-getriggerte Ausführungen dieses Maximum überschreiten, werden die Ereignisse gemäß der Eventarc-Wiederholungsrichtlinie wiederholt.

 6.000
Execution API-Anfragen zum Abrufen von Schritteinträgen Die maximale Anzahl von Anfragen an get, einen Schritteintrag aus einer Workflowausführung (pro Minute und Standort) 6.000
Anfragen für Execution API-Listenschritteinträge Die maximale Anzahl von Anfragen an list-Schritteinträge aus einer Workflowausführung (pro Minute und Standort) 1.200
Execution API-Anfragen zum Exportieren von Daten 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, die für Ausführungsressourcen aus allen Workflows in Ihrem Projekt gestellt werden (pro Minute und Standort) 1.500
Callback-Anfragen für die Liste der Execution API Die maximale Anzahl von Anfragen an list-Callbacks aus einer Workflowausführung (pro Minute und Standort) 300

Anfragen zur Kontingenterhöhung

Verwenden Sie die Google Cloud Console, um Kontingente zu erhöhen oder zu verringern. Weitere Informationen finden Sie unter Höheres Kontingent anfordern.

Kontingentnutzung überwachen

Sie können Messwerte zur Kontingentnutzung abfragen und überwachen. Ein Beispiel finden Sie unter Kontingentmesswerte überwachen. Dort wird gezeigt, wie Sie das insgesamt verbrauchte Zuteilungskontingent für Workflows abfragen. Informationen zum Monitoring von Messwerten zur Kontingentnutzung finden Sie unter Kontingentmesswerte grafisch darstellen und überwachen.

Schrittlimits

Workflows erzwingt die folgenden Schrittlimits für jeden Workflow. Für die folgenden Limits können Sie keine Änderungen beantragen:

Limit Beschreibung Wert
Aufgaben pro Schritt Die maximale Anzahl von Zuweisungen, die in einem einzelnen Schritt ausgeführt werden können 50
Bedingungen pro Schalter Die maximale Anzahl von Bedingungen, die in einem einzelnen Switch-Block ausgewertet werden können 50
Maximale Aufrufstacktiefe Die maximale Anzahl von Ebenen von Funktionsaufrufen, z. B. wenn ein untergeordneter Workflow sich selbst oder einen anderen untergeordneten Workflow aufruft, oder Standardbibliotheksfunktionsaufrufe, 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

Weitere Informationen dazu, was als Schritt gilt, finden Sie unter Nutzung optimieren.

 100.000

Limits für parallele Schritte

Workflows erzwingt die folgenden Limits, wenn parallele Schritte verwendet werden. Für die folgenden Limits können Sie keine Änderungen beantragen:

Limit Beschreibung Wert
Zweige pro Schritt Die maximale Anzahl von Verzweigungen, die in einem parallelen Schritt unterstützt werden 10
Parallele Tiefe Die maximale Tiefe, in der parallele Schritte verschachtelt werden können 2
Gleichzeitige Verzweigungen und Iterationen

Die maximale Anzahl von Verzweigungen und Iterationen, die gleichzeitig in einer einzelnen Workflowausführung ausgeführt werden können, bevor weitere Verzweigungen und Iterationen automatisch in die Warteschlange gestellt werden, um auf den Abschluss eines oder mehrerer laufender Threads zu warten.

Es gibt keine Beschränkung für die Gesamtzahl der Threads. Alle anderen Beschränkungen gelten jedoch.

20
Nicht abgefangene Ausnahmen in einem parallelen Schritt Die maximale Anzahl von nicht behandelten Ausnahmen, die während der Ausführung des Workflows (insgesamt) ausgelöst werden können 100

Ressourcenlimits

Workflows erzwingt die folgenden Nutzungslimits. Für die folgenden Limits können Sie keine Änderungen beantragen:

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 (wenn sie in einer Variablen gespeichert wird, gilt das Speicherlimit für Variablen) 2 MB
Zeitüberschreitung bei HTTP-Anforderung

Die maximal konfigurierbare Dauer für eine einzelne HTTP-Anfrage. Eine Anfrage, die das Zeitlimit überschreitet, schlägt mit einem TimeoutError fehl:

  • Bei HTTP-Anfrageschritten (http.get-, http.post-, http.request- und andere http.*-Aufrufe) beträgt die Standard-timeout 300 Sekunden (5 Minuten). Sie können eine timeout von bis zu 1.800 Sekunden (30 Minuten) konfigurieren. Wenn Sie timeout auf mehr als 1.800 Sekunden festlegen,wird ein ValueError ausgelöst.
  • Bei Connector-Aufrufen beträgt der Standardwert für connector_params.timeout 1.800 Sekunden (30 Minuten). Wenn Sie eine längere connector_params.timeout für Wiederholungsversuche oder Abfragen von Vorgängen mit langer Ausführungszeit (bis zu 1 Jahr) konfigurieren, ist jede einzelne HTTP-Anfrage auf 1.800 Sekunden begrenzt.
 1.800 Sekunden (30 Minuten)
Länge des Ausdrucks 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
  • Maximale Arbeitsspeichermenge, die Sie für alle Variablen verwenden können, die Sie in einer einzelnen Ausführung eines bestimmten Workflows definieren
  • Maximale Größe der Argumente, die Sie beim Erstellen einer Workflowausführung übergeben können
  • Maximale Größe der Eventarc-Nutzlast, die Sie übergeben können, wenn Sie eine Workflowausführung mit Ereignissen auslösen
Maximale Stringlänge in Byte bei UTF-8-Codierung 256 KB
Umgebungsvariablen Die maximale Größe für einen Definitionsstring einer benutzerdefinierten Umgebungsvariablen (KEY=value). Es können maximal 20 Variablen definiert werden. 4 KiB
Dauer der Ausführung Die maximale Dauer (von der Start- bis zur Endzeit) für eine Workflowausführung. Jeder Workflow, der dieses Limit überschreitet, endet mit einem Zeitüberschreitungsfehler. 1 Jahr
Ausführungsaufbewahrung Die maximale Aufbewahrungsdauer (nach Abschluss einer Workflowausführung) des Verlaufs und der Ergebnisse einer Ausführung 90 Tage
Deduplizierungszeitraum Das Deduplizierungsfenster, um eine genau einmalige Verarbeitung beim Auslösen einer Workflowausführung mit Ereignissen zu gewährleisten 24 Stunden