Nutzungsbeschränkungen

Da die Google Chat API ein gemeinsamer Dienst ist, wenden wir Kontingente und Einschränkungen an, um sicherzustellen, dass sie von allen Nutzern fair verwendet wird, und um 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 Ratenbegrenzungen im Chat-Backend können ebenfalls dieselbe Fehlermeldung 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 nicht überschreiten, ist die Anzahl der Anfragen, die Sie pro Tag stellen können, nicht begrenzt.

Für Chat API-Methoden können mehrere Kontingenttypen gelten: Kontingente pro Projekt, pro Bereich und pro Nutzer.

Kontingente pro Projekt

Kontingente pro Projekt begrenzen die Rate der Anfragen 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.

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)

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

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 für Gruppenbereiche

spaces.setup

spaces.create

spaces.patch

spaces.delete

60

Gruppenbereich – Lesevorgänge pro Minute

spaces.get

spaces.list

spaces.findDirectMessage

3000

Anhang – Schreibvorgänge pro Minute

media.upload

600

Anhang – Lesevorgänge pro Minute

spaces.messages.attachments.get

media.download

3000

Reaktionsschreibvorgänge pro Minute

spaces.messages.reactions.create

spaces.messages.reactions.delete

600

Reaktionslesevorgänge pro Minute

spaces.messages.reactions.list

3000

Kontingente pro Bereich

Kontingente pro Bereich begrenzen die Anzahl der Anfragen in einem bestimmten Bereich und werden von allen Chat-Apps gemeinsam genutzt, die in diesem Bereich aktiv sind und die aufgeführten Chat API-Methoden für jedes Kontingent aufrufen.

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

Kontingent pro Gruppenbereich

Chat API-Methoden

Limit (pro 60 Sekunden)

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 Beschränkungen.)

spaces.messages.delete

spaces.messages.patch

spaces.messages.reactions.create

spaces.messages.reactions.delete

60

Kontingente pro Nutzer

Kontingente pro Nutzer beschränken die Rate der Anfragen für einen Google Chat-Nutzer. Anfragen beziehen sich auf alle Chat-Apps, die im Namen eines Nutzers eine Chat API-Methode aufrufen (mithilfe der Nutzerauthentifizierung).

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

Kontingent pro Nutzer

Chat API-Methoden

Limit (pro 60 Sekunden)

Lesevorgänge pro Minute

customEmojis.get

customEmojis.list

900

Schreibvorgänge pro Minute

customEmojis.create

customEmojis.delete

60

Zusätzliche Nutzungslimits

Für das Erstellen von Gruppenbereichen des Typs GROUP_CHAT oder SPACE (mit der Methode spaces.create oder spaces.setup) gelten zusätzliche Kontingentbeschränkungen. Erstellen Sie weniger als 35 Gruppenbereiche pro Minute und 800 Gruppenbereiche pro Stunde dieser Typen. Für Bereiche vom Typ DIRECT_MESSAGE gelten diese 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 sichtbar sind.

Zeitbasierte Kontingentfehler 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, um sicherzustellen, dass Ihre Geräte keine übermäßige Last erzeugen.

Exponentieller Backoff ist eine Standardstrategie zur Fehlerbehebung für Netzwerkanwendungen. Ein exponentieller Backoff-Algorithmus wiederholt Anfragen mit exponentiell zunehmenden Wartezeiten zwischen den Anfragen bis zur maximalen Backoff-Zeit. Wenn Anfragen weiterhin fehlschlagen, ist es wichtig, dass die Verzögerungen zwischen den Anfragen mit 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, wartet das System 1 + random_number_milliseconds Sekunden und wiederholt dann 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. 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ängen von Ihrem Anwendungsfall und den Netzwerkbedingungen ab.

Kontingenterhöhung pro Projekt anfordern

Abhängig von der Ressourcennutzung Ihres Projekts können Sie eine Kontingentanpassung beantragen. API-Aufrufe durch ein Dienstkonto werden als Aufrufe über ein einzelnes Konto betrachtet. Wenn Sie ein angepasstes Kontingent beantragen, bedeutet dies nicht, dass Ihr Antrag auch genehmigt wird. Die Genehmigung von Anfragen zur Kontingentanpassung, die den Kontingentwert erheblich erhöhen würden, kann 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 Ihre Kontingentwerte möglicherweise erhöht werden. 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: