Nutzungslimits

Da es sich bei der Google Chat API um einen freigegebenen Dienst handelt, wenden wir Kontingente und Beschränkungen an, damit sie von allen Nutzern fair verwendet wird und um die Gesamtleistung von Google Workspace zu schützen.

Wenn Sie ein Kontingent überschreiten, erhalten Sie den HTTP-Statuscode 429: Too many requests. Zusätzliche Ratenbegrenzungsprüfungen für das Chat-Back-End können ebenfalls dieselbe Fehlerantwort generieren. Wenn dieser Fehler auftritt, sollten Sie einen exponentiellen Backoff-Algorithmus verwenden und es später noch einmal versuchen. Solange Sie die in den folgenden Tabellen aufgeführten Kontingente pro Minute einhalten, gibt es keine Begrenzung für die Anzahl der Anfragen, die Sie pro Tag stellen können.

Für Chat API-Methoden gelten zwei Kontingenttypen: Kontingente pro Bereich und Projekt.

Kontingente pro Bereich

Kontingente pro Bereich begrenzen die Rate von Abfragen in einem bestimmten Bereich und werden von allen Chat-Apps gemeinsam genutzt, die in diesem Bereich agieren und die aufgeführten Chat API-Methoden für jedes Kontingent aufrufen.

In der folgenden Tabelle sind die Abfragelimits pro Bereich aufgeführt:

Kontingent pro Speicherplatz

Chat API-Methoden

Limit (pro 60 Sekunden,
für alle Chat-Apps im Gruppenbereich freigegeben)

Lesevorgänge pro Minute

media.download

spaces.get

spaces.members.get

spaces.members.list

spaces.messages.get

spaces.messages.list

spaces.messages.attachments.get

spaces.messages.reactions.list

900

Schreibvorgänge pro Minute

media.upload

spaces.delete

spaces.patch

spaces.messages.create (gilt auch für eingehende Webhooks)

spaces.messages.delete

spaces.messages.patch

spaces.messages.reactions.create

spaces.messages.reactions.delete

60

Kontingente pro Projekt

Kontingente pro Projekt begrenzen die Abfragerate für ein Google Cloud-Projekt und gelten daher für eine einzelne Chat-App, die die angegebenen Chat API-Methoden für jedes Kontingent aufruft.

Die folgende Tabelle enthält die Abfragelimits pro Projekt. Sie finden diese Limits auch auf der Seite Kontingente.

Kontingent pro Projekt

Chat API-Methoden

Limit (pro 60 Sekunden)

Nachrichtenschreibvorgänge pro Minute

spaces.messages.create

spaces.messages.patch

spaces.messages.delete

3.000

Lesevorgänge pro Minute

spaces.messages.get

spaces.messages.list

3.000

Mitgliedschaftsschreibvorgänge pro Minute

spaces.members.create

spaces.members.delete

300

Mitgliedschafts-Lesevorgänge pro Minute

spaces.members.get

spaces.members.list

3.000

Speicherplatzschreibvorgänge pro Minute

spaces.setup

spaces.create

spaces.patch

spaces.delete

60

Lesevorgänge pro Minute im Bereich

spaces.get

spaces.list

spaces.findDirectMessage

3.000

Schreibvorgänge für Anhänge pro Minute

media.upload

600

Lesevorgänge pro Minute für Anhänge

spaces.messages.attachments.get

media.download

3.000

Reaktionsschreibvorgänge pro Minute

spaces.messages.reactions.create

spaces.messages.reactions.delete

600

Reaktionslesevorgänge pro Minute

spaces.messages.reactions.list

3.000

Zusätzliche Nutzungslimits

Für das Erstellen von Gruppenbereichen vom Typ GROUP_CHAT oder SPACE gelten zusätzliche Kontingentlimits (mit der Methode spaces.create oder spaces.setup). Erstellen Sie weniger als 35 Bereiche pro Minute und 210 Bereiche pro Stunde dieser Typen. Gruppenbereiche vom Typ DIRECT_MESSAGE unterliegen diesen zusätzlichen Kontingentlimits nicht.

Große Abfragen pro Sekunde bei einer API, die auf denselben Bereich ausgerichtet ist, können zusätzliche interne Limits verursachen, die auf der Seite Kontingente nicht angezeigt werden.

Fehler bei befristeten Kontingenten beheben

Bei allen zeitbasierten Fehlern (maximal N Anfragen pro X Minuten) empfehlen wir, dass Ihr Code die Ausnahme abfängt und einen abgeschnittenen exponentiellen Backoff verwendet, damit Ihre Geräte keine übermäßige Last erzeugen.

Der exponentielle Backoff ist eine standardmäßige Fehlerbehandlungsstrategie für Netzwerkanwendungen. Ein exponentieller Backoff-Algorithmus wiederholt Anfragen mit exponentiell zunehmenden Wartezeiten zwischen den Anfragen bis zu einer maximalen Backoff-Zeit. Wenn Anfragen weiterhin nicht erfolgreich sind, müssen die Verzögerungen zwischen den Anfragen mit der Zeit länger werden, bis die Anfrage erfolgreich ist.

Beispielalgorithmus

Ein exponentieller Backoff-Algorithmus wiederholt Anfragen exponentiell, wobei sich die Wartezeit zwischen zwei Wiederholungen bis zu einer maximalen Backoff-Zeit erhöht. Beispiel:

  1. Stellen Sie eine Anfrage an die Google Chat API.
  2. Wenn die Anfrage fehlschlägt, warten Sie 1 + random_number_milliseconds und wiederholen Sie die Anfrage.
  3. Wenn die Anfrage fehlschlägt, warten Sie 2 + random_number_milliseconds und wiederholen Sie die Anfrage.
  4. Wenn die Anfrage fehlschlägt, warten Sie 4 + random_number_milliseconds und wiederholen Sie die Anfrage.
  5. Und so weiter bis zur maximum_backoff-Zeit.
  6. Warten Sie weiter und führen Sie Wiederholungsversuche bis zu einer maximalen Anzahl von Wiederholungen durch, aber erhöhen Sie die Wartezeit zwischen den Wiederholungen nicht.

Dabei gilt:

  • Die Wartezeit beträgt min(((2^n)+random_number_milliseconds), maximum_backoff), wobei n bei jedem Durchlauf (Anfrage) um 1 erhöht wird.
  • random_number_milliseconds ist eine zufällige Anzahl von Millisekunden,die kleiner oder gleich 1.000 ist. Dadurch wird vermieden, dass in bestimmten Situationen viele Clients synchronisiert werden und alle den Vorgang gleichzeitig wiederholen und Anfragen in synchronisierten Wellen senden. Der Wert von random_number_milliseconds wird nach jeder Wiederholungsanfrage neu berechnet.
  • maximum_backoff ist normalerweise 32 oder 64 Sekunden lang. Der geeignete Wert hängt vom Anwendungsfall ab.

Der Client kann den Vorgang wiederholen, nachdem er die maximum_backoff-Zeit erreicht hat. Die Backoff-Zeit muss dabei nicht mehr verlängert werden. Wenn ein Client beispielsweise eine maximum_backoff-Zeit von 64 Sekunden verwendet, kann er es nach Erreichen dieses Werts alle 64 Sekunden noch einmal versuchen. An einem bestimmten Punkt sollten Clients daran gehindert werden, Wiederholungsversuche unbegrenzt auszuführen.

Die Wartezeit zwischen den Wiederholungsversuchen und die Anzahl der Wiederholungsversuche hängen von Ihrem Anwendungsfall und Ihren Netzwerkbedingungen ab.

Kontingenterhöhung pro Projekt anfordern

Abhängig von der Ressourcennutzung Ihres Projekts können Sie eine Kontingenterhöhung anfordern. Es wird davon ausgegangen, dass API-Aufrufe durch ein Dienstkonto ein einzelnes Konto nutzen. Wenn Sie ein höheres Kontingent beantragen, bedeutet dies nicht, dass Ihr Antrag auch genehmigt wird. Bei großen Kontingenterhöhungen kann die Genehmigung länger dauern.

Es gelten nicht für alle Projekte dieselben Kontingente. Da Sie Google Cloud im Laufe der Zeit immer mehr nutzen, müssen Ihre Kontingente möglicherweise erhöht werden. Wenn Sie eine deutlich stärkere Auslastung erwarten, können Sie auf der Seite „Kontingente“ in der Google Cloud Console eine Anpassung Ihres Kontingents anfordern.

Weitere Informationen finden Sie in den folgenden Ressourcen: