Nutzungslimits

Da die Google Chat API ein gemeinsam genutzter Dienst ist, wenden wir Kontingente und Beschränkungen für stellen Sie sicher, dass sie von allen Nutzern fair verwendet wird, und schützen Sie die Leistung von Google Workspace.

Wenn du ein Kontingent überschreitest, erhältst du eine HTTP-Meldung vom Typ 429: Too many requests Statuscode zurückgegeben. Zusätzliche Ratenbegrenzungsprüfungen im Chat die gleiche Fehlerantwort generieren. Wenn dieser Fehler auftritt, sollte ein exponentieller Backoff-Algorithmus und versuche es später noch einmal. Solange Sie innerhalb der Minutenkontingente bleiben, die in können Sie beliebig viele Anfragen stellen, pro Tag.

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

Kontingente pro Gruppenbereich

Kontingente pro Gruppenbereich begrenzen die Rate von Abfragen in einem bestimmten Bereich und werden zwischen alle Chat-Apps, die in diesem Gruppenbereich aktiv sind, Chat API-Methoden für jedes Kontingent.

In der folgenden Tabelle sind die Abfragelimits 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

Kontingente pro Projekt

Projektspezifische Kontingente begrenzen die Abfragerate für ein Google Cloud-Projekt. gelten also für eine einzelne Chat-App, die das angegebene Chat API-Methoden für jedes Kontingent.

In der folgenden Tabelle sind die Abfragelimits pro Projekt aufgeführt. Außerdem finden Sie Diese Limits finden Sie 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

Lesevorgänge pro Minute

spaces.messages.get

spaces.messages.list

3000

Mitgliedschaftsschreibvorgänge pro Minute

spaces.members.create

spaces.members.delete

300

Lesevorgänge pro Minute für Mitgliedschaften

spaces.members.get

spaces.members.list

3000

Speicherplatz für Schreibvorgänge pro Minute

spaces.setup

spaces.create

spaces.patch

spaces.delete

60

Lesevorgänge pro Minute im Speicherbereich

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 pro Minute auf Reaktionen

spaces.messages.reactions.list

3000

Zusätzliche Nutzungslimits

Es gibt zusätzliche Kontingentlimits für das Erstellen von Gruppenbereichen vom Typ GROUP_CHAT oder SPACE (mithilfe der Methode spaces.create oder spaces.setup). Weniger als 35 Gruppenbereiche pro Minute und 210 Gruppenbereiche pro Minute erstellen Stunden dieser Typen. Gruppenbereiche vom Typ DIRECT_MESSAGE unterliegen diesen Regeln nicht zusätzliche Kontingentlimits.

Große Abfragen pro Sekunde von APIs, die auf denselben Bereich ausgerichtet sind, können zusätzliche interne Limits, die in der Seite Kontingente:

Zeitbasierte Kontingentfehler beheben

Für alle zeitbasierten Fehler (maximal N Anfragen pro X Minuten) empfehlen wir Ihr Code fängt die Ausnahme ab und verwendet einen abgeschnittenen exponentiellen Backoff, um sicherzustellen, Geräte nicht zu stark belastet werden.

Der exponentielle Backoff ist eine Standardstrategie zur Fehlerbehandlung für Netzwerkanwendungen. Eine Der exponentielle Backoff-Algorithmus wiederholt Anfragen mit exponentiell zunehmenden Wartezeiten zwischen Anfragen bis zu einer maximalen Backoff-Zeit. Wenn Anfragen immer noch nicht erfolgreich sind, Es ist wichtig, dass die Verzögerungen zwischen Anforderungen im Laufe der Zeit zunehmen, bis die Anforderung erfolgreich ist.

Beispielalgorithmus

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

  1. Senden Sie eine Anfrage an die Google Chat API.
  2. Wenn die Anfrage fehlschlägt, warte 1 + random_number_milliseconds und versuche es dann noch einmal der Anfrage.
  3. Wenn die Anfrage fehlschlägt, warte 2 + random_number_milliseconds und versuche es dann noch einmal der Anfrage.
  4. Wenn die Anfrage fehlschlägt, warte 4 + random_number_milliseconds und versuche es dann noch einmal der Anfrage.
  5. Und so weiter bis zur maximum_backoff-Zeit.
  6. Weiter warten und es bis zu einer maximalen Anzahl von Wiederholungsversuchen wiederholen, aber die Wartezeit nicht erhöhen Zeitraum zwischen den Wiederholungsversuchen.

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 ist als oder gleich 1.000. Dadurch wird vermieden, dass viele Clients durch die und alle wiederholen den Vorgang auf einmal. Das Senden von Anfragen in synchronisierten Wellen. Der Wert von random_number_milliseconds wird nach jedem Anfrage wiederholen.
  • maximum_backoff ist normalerweise 32 oder 64 Sekunden lang. Den entsprechenden 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. Für Wenn ein Client eine maximum_backoff-Zeit von 64 Sekunden verwendet, kann der Client den Vorgang alle 64 Sekunden wiederholen. Irgendwann kann Client-Wiederholungsversuche sollte verhindert werden.

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

Kontingenterhöhung pro Projekt anfordern

Abhängig von der Ressourcennutzung Ihres Projekts können Sie ein Kontingent anfordern. erhöhen können. Es wird davon ausgegangen, dass API-Aufrufe durch ein Dienstkonto für ein einzelnes Konto. Wenn Sie ein höheres Kontingent beantragen, bedeutet dies nicht automatisch, dass Ihr Antrag genehmigt wird. Groß Die Genehmigung von Kontingenterhöhungen kann länger dauern.

Es gelten nicht für alle Projekte dieselben Kontingente. Je mehr Sie Google Cloud müssen Sie Ihre Kontingente möglicherweise erhöhen. Wenn Sie eine deutliche Nutzung steigt, können Sie proaktiv Kontingentanpassungen anfordern auf der Seite „Kontingente“ in der Google Cloud Console.

Weitere Informationen finden Sie in den folgenden Ressourcen: