Die Google Ads API erzwingt eine Ratenbegrenzung nach Abfragen pro Sekunde (QPS) sowohl für Kundennummern als auch für Google Cloud-Projekte. Neben Anfragen pro Minute (die die Häufigkeit von API-Aufrufen messen) erzwingt die Google Ads API auch Limits für Vorgänge pro Minute (die die Gesamtzahl der API-Vorgänge über Anfragen hinweg messen). Die Google Ads API verwendet einen Token-Bucket-Algorithmus, um Anfragen zu messen und ein geeignetes QPS-Limit zu bestimmen. Das genaue Limit variiert also je nach der allgemeinen Serverlast zu einem bestimmten Zeitpunkt.
Mit Ratenbegrenzungen soll verhindert werden, dass ein Nutzer den Dienst für andere Nutzer stört, indem er die Google Ads API-Server mit einer großen Anzahl von Anfragen überlastet (entweder absichtlich oder unabsichtlich).
Anfragen, die Ratenbegrenzungen verletzen, werden mit dem Fehler:
RESOURCE_TEMPORARILY_EXHAUSTED abgelehnt.
Sie können Ihre App steuern und Ratenbegrenzungen umgehen, indem Sie sowohl die Anzahl der Anfragen aktiv reduzieren als auch die QPS-Rate auf Clientseite drosseln.
Es gibt eine Reihe von Möglichkeiten, die Wahrscheinlichkeit zu verringern, dass die Ratenbegrenzung überschritten wird. Wenn Sie sich mit den Konzepten von Enterprise Integration Patterns (EIP) wie Messaging, erneute Zustellung und Drosselung vertraut machen, können Sie eine robustere Client-App entwickeln.
Die folgenden empfohlenen Vorgehensweisen sind nach Komplexität geordnet. Einfachere Strategien stehen oben, robustere, aber anspruchsvollere Architekturen folgen danach:
- Exponentielle Backoffs
- Gleichzeitige Aufgaben beschränken
- Batchanfragen
- Drosselung und Ratenbegrenzungen
- Wiedergabeliste
Exponentielle Backoffs
Wenn Ihre Anwendung einen
RESOURCE_TEMPORARILY_EXHAUSTED Fehler erhält, verwenden Sie eine
exponentielle Backoff-Richtlinie mit zufälligem Jitter, bevor Sie die fehlgeschlagene
Anfrage noch einmal senden. Bei exponentiellen Backoffs wird die Wartezeit zwischen den Wiederholungen schrittweise verlängert (z. B. 2 Sekunden, dann 4 Sekunden, dann 8 Sekunden plus eine kleine zufällige Verzögerung). So können sich die Serverlast und die Kontingent-Buckets erholen und gleichzeitig synchronisierte Wiederholungsspitzen über Clientinstanzen hinweg vermieden werden.
Gleichzeitige Aufgaben beschränken
Eine häufige Ursache für das Überschreiten von Ratenbegrenzungen ist, dass die Client-App eine übermäßige Anzahl paralleler Aufgaben erzeugt. Wir begrenzen zwar nicht die Anzahl paralleler Anfragen, die eine Client-App haben kann, aber dadurch kann das Limit für Anfragen pro Sekunde auf Google Cloud-Projektebene überschritten werden.
Es wird empfohlen, eine angemessene Obergrenze für die Gesamtzahl der gleichzeitigen Aufgaben festzulegen, die Anfragen stellen (über alle Prozesse und Maschinen hinweg), und diese nach oben anzupassen, um den Durchsatz zu optimieren, ohne die Ratenbegrenzung zu überschreiten.
Außerdem können Sie die QPS-Rate auf Clientseite drosseln (siehe Drosselung und Ratenbegrenzungen).
Batchanfragen
Sie können mehrere Vorgänge in einer einzigen Anfrage zusammenfassen. Dies ist am besten für Mutate-Aufrufe für verschiedene Dienste geeignet. Wenn Sie beispielsweise den Status für mehrere Instanzen von AdGroupAd aktualisieren, können Sie MutateAdGroupAds einmal aufrufen und mehrere operations übergeben, anstatt MutateAdGroupAds einmal für jedes AdGroupAd aufzurufen. Weitere Beispiele finden Sie in unserer
Anleitung zu Batchvorgängen.
Durch das Batching von Anfragen wird die Gesamtzahl der API-Aufrufe reduziert und die Ratenbegrenzungen für Anfragen pro Minute werden gemildert. Wenn Sie jedoch eine große Anzahl von Vorgängen für ein einzelnes Konto ausführen, kann die Ratenbegrenzung für Vorgänge pro Minute ausgelöst werden.
Drosselung und Ratenbegrenzungen
Neben der Begrenzung der Gesamtzahl der Threads in Ihrer Anwendung können Sie auch Ratenbegrenzungen auf Clientseite implementieren. So wird sichergestellt, dass alle Threads in Ihren Prozessen, Clustern oder beiden von einer bestimmten QPS-Begrenzung auf Clientseite gesteuert werden.
Sie können den Guava RateLimiter verwenden oder Ihren eigenen Token-Bucket-Algorithmus für eine Clusterumgebung implementieren. Sie können beispielsweise Tokens in einem verteilten, latenzarmen In-Memory-Datenspeicher wie Redis oder Memcached verwalten. Dort ruft jeder Client ein Token ab und verwendet es, bevor er eine Anfrage verarbeitet. Wenn die Tokens aufgebraucht sind, wartet der Client, bis der nächste Batch von Tokens aufgefüllt wird.
Wiedergabeliste
Eine Nachrichtenwarteschlange ist die Lösung für die Verteilung der Vorgangslast und die Steuerung der Anfragen- und Verbraucherraten. Es gibt eine Reihe von Optionen für Nachrichtenwarteschlangen, einige Open Source, einige proprietär. Viele von ihnen können mit verschiedenen Sprachen verwendet werden.
Wenn Sie Nachrichtenwarteschlangen verwenden, können mehrere Producer Nachrichten in die Warteschlange senden und mehrere Consumer diese Nachrichten verarbeiten. Drosselungen können auf Consumerseite implementiert werden, indem die Anzahl der gleichzeitigen Consumer begrenzt wird oder indem Ratenbegrenzungen oder Drosselungen für die Producer oder Consumer implementiert werden.
Wenn ein Nachrichten-Consumer beispielsweise auf einen Fehler aufgrund einer Ratenbegrenzung stößt, kann er die Anfrage mit einer standardmäßigen Wiederholungsverzögerung (mit exponentiellen Backoffs) an die Warteschlange zurückgeben und eine gemeinsame Feedbackschleife für die Ratenbegrenzung aktualisieren, sodass alle Consumer ihre Verarbeitungsrate automatisch reduzieren, während sie sich von dem Fehler erholen.