Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
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.
In der Google API Console wird dieses Kontingent als Abfragen pro Minute pro Nutzer bezeichnet und ist auf 240 festgelegt.
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:
Stellen Sie eine Anfrage an die API.
Sie erhalten eine HTTP 503-Antwort, die angibt, dass Sie die Anfrage wiederholen müssen.
Warten Sie 1 Sekunde + random_number_milliseconds und wiederholen Sie die Anfrage.
Sie erhalten eine HTTP 503-Antwort, die angibt, dass Sie die Anfrage wiederholen müssen.
Warten Sie 2 Sekunden + random_number_milliseconds und wiederholen Sie die Anfrage.
Sie erhalten eine HTTP 503-Antwort, die angibt, dass Sie die Anfrage wiederholen müssen.
Warten Sie 4 Sekunden + random_number_milliseconds und wiederholen Sie die Anfrage.
Sie erhalten eine HTTP 503-Antwort, die angibt, dass Sie die Anfrage wiederholen müssen.
Warten Sie 8 Sekunden + random_number_milliseconds und wiederholen Sie die Anfrage.
Sie erhalten eine HTTP 503-Antwort, die angibt, dass Sie die Anfrage wiederholen müssen.
Warten Sie 16 Sekunden + random_number_milliseconds Millisekunden und wiederholen Sie die Anfrage.
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.
Rufen Sie in der Google API Console die Bid Manager API auf.
Ü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.
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.
