Nutzungsbeschränkungen

Da die Google Chat API ein gemeinsam genutzter Dienst ist, gelten Kontingente und Einschränkungen, damit sie von allen Nutzern fair genutzt wird und die Gesamtleistung von Google Workspace geschützt wird.

Wenn Sie ein Kontingent überschreiten, erhalten Sie den HTTP-Statuscode 429: Too many requests. Zusätzliche Prüfungen der Ratenbeschränkung im Chat-Backend können ebenfalls zu derselben Fehlerantwort führen. 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, ist die Anzahl der Anfragen pro Tag nicht begrenzt.

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

Kontingente pro Gruppenbereich

Kontingente pro Gruppenbereich begrenzen die Anzahl der Abfragen in einem bestimmten Gruppenbereich und werden für alle Chat-Apps geteilt, die in diesem Gruppenbereich aktiv sind und die aufgeführten Chat API-Methoden für jedes Kontingent aufrufen.

In der folgenden Tabelle sind die Limits für Abfragen pro Gruppenbereich aufgeführt:

Kontingent pro Gruppenbereich

Chat API-Methoden

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

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

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

In der folgenden Tabelle sind die Limits für Abfragen pro Projekt aufgeführt. Sie finden diese Limits auch auf der Seite Kontingente.

Kontingent pro Projekt

Chat API-Methoden

Limit (pro 60 Sekunden)

Schreibvorgänge für Nachrichten pro Minute

spaces.messages.create

spaces.messages.patch

spaces.messages.delete

3000

Nachrichtenlesevorgänge pro Minute

spaces.messages.get

spaces.messages.list

3000

Mitgliedschaftsschreibvorgänge pro Minute

spaces.members.create

spaces.members.delete

300

Mitgliedschaft – Lesevorgänge pro Minute

spaces.members.get

spaces.members.list

3000

Schreibvorgänge pro Minute

spaces.setup

spaces.create

spaces.patch

spaces.delete

60

Lesevorgänge pro Minute

spaces.get

spaces.list

spaces.findDirectMessage

3000

Anhang – Schreibvorgänge pro Minute

media.upload

600

Lesevorgänge für Anhänge pro Minute

spaces.messages.attachments.get

media.download

3000

Schreibvorgänge für Reaktionen pro Minute

spaces.messages.reactions.create

spaces.messages.reactions.delete

600

Lesevorgänge für Reaktionen pro Minute

spaces.messages.reactions.list

3000

Zusätzliche Nutzungslimits

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

Hoher API-Traffic, der auf denselben Bereich ausgerichtet ist, kann zusätzliche interne Limits auslösen, die auf der Seite Kontingente nicht angezeigt werden.

Zeitbasierte Kontingentfehler beheben

Bei allen zeitbasierten Fehlern (maximal N Anfragen pro X Minuten) empfehlen wir, dass Ihr Code die Ausnahme abfängt und ein abgeschnittenes exponentielles Backoff verwendet, damit Ihre Geräte keine übermäßige Auslastung verursachen.

Der exponentielle Backoff ist eine Standardstrategie zur Fehlerbehandlung für Netzwerkanwendungen. Ein exponentieller Backoff-Algorithmus wiederholt Anfragen mit exponentiell zunehmenden Wartezeiten zwischen den Anfragen bis zur maximalen Backoff-Zeit. Wenn die Anfragen weiterhin fehlschlagen, ist es wichtig, dass die Verzögerungen zwischen den Anfragen im Laufe der Zeit zunehmen, bis die Anfrage erfolgreich ist.

Beispielalgorithmus

Ein exponentieller Backoff-Algorithmus wiederholt Anfragen exponentiell und verlängert dabei die Wartezeit zwischen zwei Wiederholungen bis zur maximalen Backoff-Zeit. 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, wartet das System 2 + random_number_milliseconds Sekunden und wiederholt dann die Anfrage.
  4. Wenn die Anfrage fehlschlägt, wartet das System 4 + random_number_milliseconds Sekunden und wiederholt dann die Anfrage.
  5. Und so weiter bis zur maximum_backoff-Zeit.
  6. Das System wartet weiter und führt erneute Versuche bis zu einer maximalen Anzahl an Wiederholungsversuchen aus, jedoch ohne den zeitlichen Abstand zwischen zwei Versuchen zu erhöhen.

Dabei gilt:

  • Die Wartezeit beträgt min(((2^n)+random_number_milliseconds), maximum_backoff), wobei n bei jeder Ausführung (Anfrage) um 1 erhöht wird.
  • random_number_milliseconds steht für eine zufällige Anzahl von Millisekunden,deren Wert größer oder gleich 1.000 ist. Dadurch wird vermieden, dass viele Clients synchronisiert werden und alle gleichzeitig Anfragen wiederholen und Anfragen in synchronisierten Wellen senden. Der Wert von random_number_milliseconds wird nach jeder Anfragewiederholung 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 nach Erreichen dieses Werts alle 64 Sekunden einen neuen Versuch starten. Sie sollten jedoch dafür sorgen, dass er dies nicht unbegrenzt tut.

Die Wartezeit zwischen Wiederholungen und die Anzahl der Wiederholungen hängen vom Anwendungsfall und den Netzwerkbedingungen ab.

Kontingenterhöhung pro Projekt anfordern

Je nach Ressourcennutzung Ihres Projekts können Sie eine Kontingenterhöhung beantragen. Es wird davon ausgegangen, dass API-Aufrufe durch ein Dienstkonto ein einzelnes Konto verwenden. 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. Wenn Sie Google Cloud im Laufe der Zeit häufiger nutzen, müssen Sie Ihre Kontingente möglicherweise erhöhen. Falls Sie eine deutlich stärkere Auslastung erwarten, können Sie auf der Seite Kontingente der Google Cloud Console eine Anpassung Ihres Kontingents anfordern.

Weitere Informationen finden Sie in den folgenden Ressourcen: