Diese Seite wurde von der Cloud Translation API übersetzt.

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 eine Antwort mit dem HTTP-Statuscode 429: Too many requests. Zusätzliche Prüfungen der Ratenbeschränkung im Chat-Backend können ebenfalls zu derselben Fehlerantwort führen. 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, die Sie pro Tag stellen können, 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 verwendet)
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` (Für eingehende Webhooks gelten zusätzliche Limits.) `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,
wird für alle Chat-Apps im Gruppenbereich verwendet)

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 (Für eingehende Webhooks gelten zusätzliche Limits.)

spaces.messages.delete

spaces.messages.patch

spaces.messages.reactions.create

spaces.messages.reactions.delete

Projektspezifische Kontingente

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 finden Sie die Limits für Abfragen 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`	3000
Nachrichtenlesevorgänge pro Minute	`spaces.messages.get` `spaces.messages.list`	3000
Mitgliedschaft – Schreibvorgä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 diesen zusätzlichen Kontingentlimits nicht.

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

Fehler bei zeitbasierten Kontingenten 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.

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 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:

Stellen 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, wartet das System 4 + random_number_milliseconds Sekunden und wiederholt dann 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 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. 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 Anfragewiederholung neu berechnet.
maximum_backoff ist normalerweise 32 oder 64 Sekunden lang. Der geeignete Wert hängt vom jeweiligen 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. API-Aufrufe durch ein Dienstkonto gelten als Verwendung eines einzelnen Kontos. 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: