Ratenlimits

In der Google Ads API werden Anfragen für die Ratenbegrenzung nach Abfragen pro Sekunde (Queries per Second, QPS) pro Kunden-ID (Customer ID, CID) und Entwicklertoken gruppiert. Das bedeutet, dass die Messung unabhängig für CIDs und Entwicklertokens erfolgt. In der Google Ads API wird ein Token Bucket-Algorithmus verwendet, 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 Ratenlimits soll verhindert werden, dass ein Nutzer den Dienst für andere Nutzer stört, indem er die Google Ads API-Server (absichtlich oder unabsichtlich) mit einer großen Anzahl von Anfragen überlastet.

Anfragen, die gegen Ratenlimits verstoßen, werden mit dem Fehler: RESOURCE_TEMPORARILY_EXHAUSTED abgelehnt.

Sie können Ihre App steuern und Ratenlimits umgehen, indem Sie sowohl die Anzahl der Anfragen aktiv reduzieren als auch die QPS auf Clientseite drosseln.

Es gibt eine Reihe von Möglichkeiten, die Wahrscheinlichkeit zu verringern, dass das Ratenlimit überschritten wird. Wenn Sie sich mit den Konzepten von Enterprise Integration Patterns (EIP) wie Messaging, Redelivery und Throttling 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 weiter unten:

Anzahl gleichzeitiger Aufgaben beschränken

Eine häufige Ursache für das Überschreiten von Ratenlimits ist, dass die Client-App eine übermäßige Anzahl paralleler Aufgaben erzeugt. Wir begrenzen zwar nicht die Anzahl paralleler Anfragen, die eine Client-App stellen kann, aber dadurch kann das Limit für Anfragen pro Sekunde auf Entwicklertoken-Ebene überschritten werden.

Es wird empfohlen, eine angemessene Obergrenze für die Gesamtzahl der gleichzeitigen Aufgaben festzulegen, die Anfragen stellen (für alle Prozesse und Maschinen), und diese nach oben anzupassen, um den Durchsatz zu optimieren, ohne das Ratenlimit zu überschreiten.

Außerdem können Sie die QPS auf Clientseite drosseln (siehe Drosselung und Ratenbegrenzungen).

Batchanfragen

Sie können mehrere Vorgänge in einer einzelnen Anfrage zusammenfassen. Dies ist am besten für MutateFoo-Aufrufe geeignet. Wenn Sie beispielsweise den Status für mehrere Instanzen von AdGroupAd aktualisieren, können Sie MutateAdGroupAds nur einmal aufrufen und mehrere operations übergeben, anstatt MutateAdGroupAds einmal für jede AdGroupAd aufzurufen. Weitere Beispiele finden Sie in unserer Anleitung zu Batchvorgängen.

Durch das Zusammenfassen von Anfragen wird die Gesamtzahl der Anfragen reduziert und das Ratenlimit für Anfragen pro Minute wird weniger wahrscheinlich überschritten. Wenn Sie jedoch eine große Anzahl von Vorgängen für ein einzelnes Konto ausführen, kann das Ratenlimit für Vorgänge pro Minute ausgelöst werden.

Drosselung und Ratenbegrenzungen

Neben der Begrenzung der Gesamtzahl von Threads in Ihrer Client-Anwendung können Sie auch Ratenbegrenzungen für den Client implementieren. So können Sie sicherstellen, dass alle Threads in Ihren Prozessen und / oder Clustern auf Clientseite durch ein bestimmtes QPS-Limit begrenzt werden.

Sie können Guava Rate Limiter verwenden oder einen eigenen Token Bucket-basierten Algorithmus für eine Clusterumgebung implementieren. Sie könnten beispielsweise Tokens generieren und in einem gemeinsamen transaktionalen Speicher wie einer Datenbank speichern. Jeder Client muss ein Token erwerben und verwenden, bevor er die Anfrage verarbeitet. Wenn die Tokens aufgebraucht sind, muss der Client warten, bis der nächste Batch von Tokens generiert 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, sowohl Open-Source- als auch proprietäre, und viele von ihnen können mit verschiedenen Sprachen verwendet werden.

Wenn Sie Nachrichtenwarteschlangen verwenden, können mehrere Producer Nachrichten in die Warteschlange stellen und mehrere Consumer diese Nachrichten verarbeiten. Sie können die Anzahl gleichzeitiger Empfänger drosseln oder Ratenbegrenzungen/Drosselungen für Sender oder Empfänger erstellen.

Wenn bei einem Nachrichtenempfänger beispielsweise ein Fehler aufgrund eines Ratenlimits auftritt, kann er die Anfrage an die Warteschlange zurückgeben, damit sie noch einmal versucht wird. Gleichzeitig kann dieser Empfänger auch alle anderen Empfänger benachrichtigen, die Verarbeitung für einige Sekunden zu pausieren, um den Fehler zu beheben.