Kontingente

Kontingente schützen die Infrastruktur von Google vor automatisierten Prozessen, die die Google Bid Manager API auf unzulässige Weise nutzen. Sie stellen sicher, dass die Aktionen eines Entwicklers keine negativen Auswirkungen auf die gesamte Community haben.

Kontingentlimits

Die folgenden standardmäßigen Kontingentlimits werden von allen Ressourcen und Methoden der Bid Manager API gemeinsam genutzt.

• 2.000 Anfragen pro Projekt und Tag – kann erhöht werden.
• 4 Abfragen pro Sekunde pro Projekt
  • In der Google API Console wird dieses Kontingent als Abfragen pro Minute pro Nutzer bezeichnet und ist auf 240 festgelegt.

Hinweis :Die Tageskontingente werden um Mitternacht (PST) aktualisiert.

Kontingentlimits überschreiten

In dem unwahrscheinlichen Fall, dass Ihre Anfrage aufgrund einer Überschreitung eines Kontingentlimits fehlschlägt, gibt die API einen HTTP-Statuscode und die Ursache für den Fehler zurück. Darüber hinaus enthält der Text der Antwort eine detaillierte Beschreibung der Fehlerursache. Im Leitfaden zu Fehlermeldungen finden Sie ein Beispiel für eine Fehlerantwort.

Die folgende Liste enthält mögliche Fehler und empfohlene Maßnahmen für Anfragefehler, die durch das Überschreiten von Kontingentlimits verursacht werden.

Code	Grund	die Botschaft und	Empfohlene Maßnahme
403	dailyLimitExceeded	Tageslimit überschritten	Wiederholen Sie den Vorgang nur, wenn das Problem behoben ist. Untersuchen Sie Ihre Nutzung über die Google API Console und ändern Sie Ihren Workflow so, dass weniger Anfragen gestellt werden. Sie können ein zusätzliches Kontingent anfordern, wenn Sie der Meinung sind, dass Ihre Nutzung angemessen ist.
403	userRateLimitExceeded	Grenzwert für Benutzerrate überschritten	Verlangsamen Sie die Geschwindigkeit, mit der Anfragen gesendet werden, mithilfe des exponentiellen Backoffs.

Was ist ein exponentieller Backoff?

Exponentielle Backoffs bilden eine Standard-Fehlerbehandlungsstrategie für Netzwerkanwendungen, bei denen der Client eine fehlgeschlagene Anfrage über einen immer länger werdenden Zeitraum periodisch wiederholt. Wenn bei sehr vielen Anfragen oder bei hohem Netzwerktraffic der Server Fehler ausgibt, kann ein exponentieller Backoff eine hilfreiche Strategie zur Fehlerbehandlung sein. Dagegen ist ein exponentieller Backoff keine gute Strategie für die Handhabung von Fehlern, die nicht aufgrund des Netzwerkvolumens oder von Antwortzeiten auftreten, z. B. Fehler wegen ungültiger Autorisierungsdaten oder nicht gefundener Dateien.

Bei richtigem Einsatz erhöht der exponentielle Backoff die Effizienz der Bandbreitennutzung, verringert die Anzahl der Anfragen, die für den Erhalt einer erfolgreichen Antwort erforderlich sind, und maximiert den Durchsatz von Anfragen in Umgebungen mit Gleichzeitigkeit.

Der Ablauf für das Implementieren eines einfachen exponentiellen Backoffs sieht so aus:

1. Stellen Sie eine Anfrage an die API.
2. Sie erhalten eine HTTP 503-Antwort, die angibt, dass Sie die Anfrage wiederholen müssen.
3. Warten Sie 1 Sekunde + random_number_milliseconds und wiederholen Sie die Anfrage.
4. Sie erhalten eine HTTP 503-Antwort, die angibt, dass Sie die Anfrage wiederholen müssen.
5. Warten Sie 2 Sekunden + random_number_milliseconds und wiederholen Sie die Anfrage.
6. Sie erhalten eine HTTP 503-Antwort, die angibt, dass Sie die Anfrage wiederholen müssen.
7. Warten Sie 4 Sekunden + random_number_milliseconds und wiederholen Sie die Anfrage.
8. Sie erhalten eine HTTP 503-Antwort, die angibt, dass Sie die Anfrage wiederholen müssen.
9. Warten Sie 8 Sekunden + random_number_milliseconds und wiederholen Sie die Anfrage.
10. Sie erhalten eine HTTP 503-Antwort, die angibt, dass Sie die Anfrage wiederholen müssen.
11. Warten Sie 16 Sekunden + random_number_milliseconds Millisekunden und wiederholen Sie die Anfrage.
12. Beenden Sie den Vorgang. Melden oder protokollieren Sie einen Fehler.

Im oben beschriebenen Ablauf steht random_number_milliseconds für eine zufällige Anzahl von Millisekunden, deren Wert größer oder gleich 1.000 ist. Dies ist erforderlich, da eine kurze zufällige Verzögerung die Last gleichmäßiger verteilt und verhindert, dass der Server blockiert wird. Der Wert von random_number_milliseconds muss nach jeder Wartezeit neu definiert werden.

Hinweis: Die Wartezeit beträgt immer (2 ^ n) + random_number_milliseconds Millisekunden, wobei n eine gleichförmig ansteigende Ganzzahl ist, die anfänglich auf 0 gesetzt ist. Die Ganzzahl n wird bei jeder Iteration bzw. Anfrage um 1 erhöht.

Der Algorithmus ist so eingerichtet, dass er endet, wenn n = 5. Diese Obergrenze verhindert, dass die Clients unendlich fortfahren, und führt zu einer Verzögerung von insgesamt 32 Sekunden, bevor eine Anfrage als "nicht zu behebender Fehler" gilt. Sie können eine größere maximale Anzahl an Wiederholungen angeben, insbesondere wenn es sich um einen langen Upload handelt. Wichtig ist nur, dass die Wiederholungsverzögerung bei einem akzeptablen Wert liegt, zum Beispiel bei unter einer Minute.

Zusätzliches Tageskontingent anfordern

Wenn Sie der Meinung sind, dass für Ihre Anwendung ein zusätzliches Tageskontingent erforderlich ist, können Sie anhand der folgenden Anleitung ein höheres Kontingent anfordern.

Die folgende Anleitung gilt nur für Projekte, bei denen der Fehler dailyLimitExceeded aufgetreten ist. Empfohlene Maßnahmen für andere Kontingentfehler finden Sie in der Tabelle oben.

1. Rufen Sie in der Google API Console die Bid Manager API auf.
2. Überprüfen Sie die Nutzungsstatistiken auf der Seite Messwerte, um sicherzustellen, dass sich Ihre Anwendung erwartungsgemäß verhält. Achten Sie genau auf die aufgerufenen Methoden und beheben Sie unerwartete oder übermäßige Verwendung, bevor Sie fortfahren.
3. Wenn die Nutzung normal aussieht, rufen Sie die Seite Kontingente auf. Klicken Sie auf das Bearbeitungssymbol neben Abfragen pro Tag und dann auf den Link „Höheres Kontingent beantragen“.

Lesen Sie die Informationen und folgen Sie der Anleitung im Formular zum Anfordern einer Kontingenterhöhung, bevor Sie eine Erhöhung beantragen.

Hinweis :Die von Ihnen angegebene E-Mail-Adresse muss eine Adresse sein, die Sie aktiv im Blick behalten, da sich ein Mitarbeiter an Sie wenden kann, um weitere Informationen zu erhalten.