Diese Seite wurde von der Cloud Translation API übersetzt.

Nutzungsbeschränkungen

Da die Google Chat API ein gemeinsam genutzter Dienst ist, wenden wir Kontingente und Beschränkungen an, um eine faire Nutzung durch alle Nutzer sicherzustellen und die Gesamtleistung von Google Workspace zu schützen.

Wenn Sie ein Kontingent überschreiten, erhalten Sie eine Antwort mit dem HTTP-Statuscode 429: Too many requests. Zusätzliche Ratenbegrenzungsprüfungen im Chat-Back-End können ebenfalls die gleiche Fehlerantwort generieren. In diesem Fall 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, geteilt in allen Chat-Apps im Gruppenbereich)
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

Kontingent pro Gruppenbereich

Chat API-Methoden

Limit (pro 60 Sekunden, geteilt
in allen Chat-Apps im Gruppenbereich)

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

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 Abfragelimits pro Projekt aufgeführt. 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`	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
Schreibvorgänge für Anhänge pro Minute	`media.upload`	600
Lesevorgänge von Anhängen pro Minute	`spaces.messages.attachments.get` `media.download`	3000
Reaktionsschreibvorgänge 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 gelten zusätzliche Kontingentlimits mit der Methode spaces.create oder spaces.setup. Sie dürfen nicht mehr als 35 Gruppenbereiche pro Minute und 800 Gruppenbereiche pro Stunde dieser Art erstellen. Gruppenbereiche vom Typ DIRECT_MESSAGE unterliegen diesen zusätzlichen Kontingentlimits nicht.

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 der Code die Ausnahme abfängt und einen abgeschnittenen exponentiellen Backoff verwendet, damit Ihre Geräte keine übermäßige Last erzeugen.

Exponentielle Backoffs bilden eine Standard-Fehlerbehandlungsstrategie für Netzwerkanwendungen. Ein exponentieller Backoff-Algorithmus wiederholt Anfragen mit exponentiell zunehmenden Wartezeiten zwischen den Anfragen bis zur maximalen Backoff-Zeit. Wenn Anfragen immer noch nicht erfolgreich sind, ist es wichtig, dass die Verzögerungen zwischen Anfragen mit der Zeit größer werden, bis die Anfrage erfolgreich ist.

Beispielalgorithmus

Ein exponentieller Backoff-Algorithmus wiederholt Anfragen exponentiell, wobei die Wartezeit zwischen Wiederholungen bis zur maximalen Backoff-Zeit erhöht wird. Beispiel:

Senden Sie eine Anfrage an die Google Chat API.
Wenn die Anfrage fehlschlägt, wartet das System 1 + random_number_milliseconds Sekunden und wiederholt dann die Anfrage.
Wenn die Anfrage fehlschlägt, wartet das System 2 + random_number_milliseconds Sekunden und wiederholt dann die Anfrage.
Wenn die Anfrage fehlschlägt, warten Sie vier + random_number_milliseconds und wiederholen Sie die Anfrage.
Und so weiter bis zur maximum_backoff-Zeit.
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 Iteration (Anfrage) um 1 erhöht wird.
random_number_milliseconds ist eine zufällige Anzahl von Millisekunden,die kleiner oder gleich 1.000 ist. So lassen sich Situationen vermeiden, in denen viele Clients synchronisiert werden und alle gleichzeitig Anfragen wiederholen und diese 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 den Vorgang nach Erreichen dieses Werts alle 64 Sekunden noch einmal versuchen. Sie sollten jedoch dafür sorgen, dass er dies nicht unbegrenzt tut.

Die Wartezeit zwischen den Wiederholungen und die Anzahl der Wiederholungen hängt von Ihrem 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. Wenn Sie eine deutlich stärkere Auslastung erwarten, können Sie proaktiv auf der Seite „Kontingente“ der Google Cloud Console eine Anpassung Ihres Kontingents anfordern.

Weitere Informationen finden Sie in den folgenden Ressourcen: