Da die Google Workspace Events 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 die Antwort mit dem HTTP-Statuscode 429: Too many requests. Zusätzliche Ratenbegrenzungsüberprüfungen im Backend der Google Workspace Events API können ebenfalls zu derselben Fehlerantwort führen. In diesem Fall sollten Sie einen Algorithmus für exponentielles Backoff 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.
Projektspezifische Kontingente
Pro-Projekt-Kontingente begrenzen die Anzahl der Abfragen für ein Google Cloud-Projekt und gelten daher für eine einzelne App, die die angegebenen Google Workspace Events API-Methoden für jedes Kontingent aufruft.
In der folgenden Tabelle finden Sie die Limits für Abfragen pro Projekt. Sie finden diese Limits auch auf der Seite Kontingente in der Google Cloud Console.
Kontingent pro Projekt |
Methoden der Google Workspace Events API |
Limit |
|---|---|---|
Schreibvorgänge pro Minute |
|
600 |
Schreibvorgänge pro Minute und Nutzer |
|
100 |
Lesevorgänge pro Minute |
|
600 |
Lesevorgänge pro Minute und Nutzer |
|
100 |
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 nicht überlastet werden.
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 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:
- Stellen Sie eine Anfrage an die Google Workspace Events API.
- Wenn die Anfrage fehlschlägt, wartet das System 1 +
random_number_millisecondsSekunden und wiederholt dann die Anfrage. - Wenn die Anfrage fehlschlägt, wartet das System 2 +
random_number_millisecondsSekunden und wiederholt dann die Anfrage. - Wenn die Anfrage fehlschlägt, wartet das System 4 +
random_number_millisecondsSekunden 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), wobeinbei jeder Ausführung (Anfrage) um 1 erhöht wird. random_number_millisecondssteht 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 vonrandom_number_millisecondswird nach jeder Anfragewiederholung neu berechnet.maximum_backoffist 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: