Diese Seite wurde von der Cloud Translation API übersetzt.

Nutzungslimits

Da es sich bei der Google Workspace Events API um einen gemeinsam genutzten Dienst handelt, wenden wir Kontingente und Beschränkungen an, damit sie von allen Nutzern fair verwendet wird und die Gesamtleistung von Google Workspace geschützt bleibt.

Wenn Sie ein Kontingent überschreiten, erhalten Sie den HTTP-Statuscode 429: Too many requests. Zusätzliche Ratenbegrenzungsprüfungen für das Back-End der Google Workspace Events API können ebenfalls dieselbe Fehlerantwort generieren. Wenn dieser Fehler auftritt, verwenden Sie einen exponentiellen Backoff-Algorithmus und versuchen Sie es später noch einmal. Solange Sie innerhalb der Minutenkontingente bleiben, die in den folgenden Tabellen aufgeführt sind, gibt es keine Begrenzung für die Anzahl der Anfragen, die Sie pro Tag stellen können.

Kontingente pro Projekt

Kontingente pro Projekt begrenzen die Abfragerate für ein Google Cloud-Projekt und gelten somit für eine einzelne Anwendung, die die angegebenen Google Workspace Events API-Methoden für jedes Kontingent aufruft.

Die folgende Tabelle enthält die Abfragelimits pro Projekt. Sie finden diese Limits auch in der Google Cloud Console auf der Seite Kontingente.

Kontingent pro Projekt	Google Workspace Events API-Methoden	Limit
Schreibvorgänge pro Minute	`Subscriptions.create` `Subscriptions.patch` `Subscriptions.delete` `Subscriptions.reactivate`	600
Schreibvorgänge pro Minute und Nutzer	`Subscriptions.create` `Subscriptions.patch` `Subscriptions.delete` `Subscriptions.reactivate`	100
Lesevorgänge pro Minute	`Subscriptions.get` `Subscriptions.list`	600
Lesevorgänge pro Minute und Nutzer	`Subscriptions.get` `Subscriptions.list`	100

Zeitbasierte Kontingentfehler beheben

Bei allen zeitbasierten Fehlern (maximal N Anfragen pro X Minuten) wird empfohlen, dass Ihr Code die Ausnahme abfängt und einen abgeschnittenen exponentiellen Backoff verwendet, damit Ihre Geräte keine übermäßige Last generieren.

Der exponentielle Backoff ist eine standardmäßige Fehlerbehandlungsstrategie für Netzwerkanwendungen. Ein exponentieller Backoff-Algorithmus wiederholt Anfragen mit exponentiell zunehmenden Wartezeiten zwischen Anfragen bis zu einer maximalen Backoff-Zeit. Wenn Anfragen weiterhin nicht erfolgreich sind, ist es wichtig, dass die Verzögerungen zwischen Anfragen im Laufe der Zeit zunimmt, bis die Anfrage erfolgreich ist.

Beispielalgorithmus

Ein exponentieller Backoff-Algorithmus wiederholt Anfragen exponentiell und verlängert dabei die Wartezeit zwischen Wiederholungen bis zur maximalen Backoff-Zeit. Beispiel:

Senden Sie eine Anfrage an die Google Workspace Events API.
Wenn die Anfrage fehlschlägt, warten Sie 1 + random_number_milliseconds und wiederholen Sie die Anfrage.
Wenn die Anfrage fehlschlägt, warten Sie „2 + random_number_milliseconds“ und wiederholen Sie die Anfrage.
Wenn die Anfrage fehlschlägt, warten Sie „4 + random_number_milliseconds“ und wiederholen Sie die Anfrage.
Und so weiter bis zur maximum_backoff-Zeit.
Warten Sie weiter und führen Sie Wiederholungsversuche bis zu einer bestimmten maximalen Anzahl von Wiederholungen durch, aber verlängern Sie nicht die Wartezeit zwischen den Wiederholungsversuchen.

Dabei gilt:

Die Wartezeit beträgt min(((2^n)+random_number_milliseconds), maximum_backoff), wobei n bei jedem Durchlauf (Anfrage) um 1 erhöht wird.
random_number_milliseconds ist eine zufällige Anzahl von Millisekunden,die kleiner oder gleich 1.000 ist. Dadurch wird vermieden, dass in bestimmten Situationen viele Clients synchronisiert werden und alle den Vorgang gleichzeitig wiederholen und Anfragen 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 nach Erreichen dieses Werts alle 64 Sekunden einen neuen Versuch starten. An einem bestimmten Punkt sollten Clients daran gehindert werden, Wiederholungen unbegrenzt auszuführen.

Die Wartezeit zwischen den Wiederholungsversuchen und die Anzahl der Wiederholungsversuche hängen von Ihrem Anwendungsfall und Ihren Netzwerkbedingungen ab.

Kontingenterhöhung pro Projekt anfordern

Abhängig von der Ressourcennutzung Ihres Projekts können Sie eine Kontingenterhöhung anfordern. Bei API-Aufrufen durch ein Dienstkonto wird davon ausgegangen, dass sie ein einzelnes Konto nutzen. Die Beantragung eines höheren Kontingents garantiert keine Genehmigung. Die Genehmigung großer Kontingenterhöhungen kann länger dauern.

Es gelten nicht für alle Projekte dieselben Kontingente. Da Sie Google Cloud im Laufe der Zeit immer mehr nutzen, müssen Ihre Kontingente möglicherweise erhöht werden. Wenn Sie eine deutlich stärkere Auslastung erwarten, können Sie auf der Seite „Kontingente“ in der Google Cloud Console eine Anpassung Ihres Kontingents anfordern.

Weitere Informationen finden Sie in den folgenden Ressourcen: