Die Nutzung Ihres Schlüssels überwachen, bevor Sie an ein Limit stoßen
Wenn Sie Ihre Kontingent-Header laufend beobachten, wissen Sie, wann ein Limit näher rückt, lange bevor eine Anfrage tatsächlich abgelehnt wird.
Sinnvolle Timeouts für umfangreiche Batch-Jobs festlegen
Ein Timeout-Wert, der für eine einzelne Adressabfrage gut funktioniert, bricht eine Bulk-Anfrage mit einigen tausend Elementen ab, lange bevor der Server alle verarbeitet hat. Das sieht wie ein Fehler aus, obwohl die Anfrage mit genug Zeit abgeschlossen worden wäre.
Warum Bulk-Anfragen mehr Zeit brauchen
Jedes Element in einem Bulk-Array ist eine eigenständige Abfrage. Eine Anfrage mit 2.000 Elementen bedeutet also ungefähr das 2.000-Fache an Verarbeitung einer einzelnen Abfrage, auch wenn es von Ihrer Seite ein einziger HTTP-Aufruf ist. Ein Timeout von ein oder zwei Sekunden, angemessen für eine einzelne Adresse, reicht für eine Anfrage dieser Größe bei Weitem nicht aus.
Das Timeout an den Batch anpassen
Legen Sie das Timeout Ihres Clients proportional zur Größe des gesendeten Arrays fest, mit etwas Spielraum für übliche Schwankungen, statt einen einzigen festen Wert für jede Anfrage Ihres Codes zu verwenden, ob klein oder groß.
timeout_seconds = max(5, item_count * 0.05)Das ist ein Ausgangspunkt, den Sie anhand Ihres eigenen beobachteten Verhaltens feinjustieren, keine feste Zahl, die als maßgeblich gilt, da die tatsächliche Verarbeitungszeit pro Element keine veröffentlichte Garantie ist.
Kleinere Blöcke statt einer riesigen Anfrage
Statt die Timeout-Werte immer weiter zu erhöhen, um eine immer größere Einzelanfrage unterzubringen, teilen Sie einen sehr großen Job in Blöcke von jeweils einigen hundert bis einigen tausend Elementen auf. Kleinere Blöcke brauchen kürzere, besser vorhersehbare Timeouts, und ein Fehler mittendrin kostet Sie nur den aktuellen Block statt des gesamten Jobs.
Umgang mit einem tatsächlich auftretenden Timeout
Wenn eine Anfrage auf Ihrer Seite tatsächlich in ein Timeout läuft, wissen Sie möglicherweise nicht, ob der Server sie dennoch fertig verarbeitet hat. Statt denselben Block blind erneut zu senden, was doppelt auf Ihr Kontingent angerechnet werden könnte, falls die ursprüngliche Anfrage abgeschlossen wurde, prüfen Sie die Kontingent-Header Ihres letzten erfolgreichen Aufrufs, um abzuschätzen, ob der abgebrochene Block wahrscheinlich durchgegangen ist, und senden Sie ihn nur mit Bedacht erneut.
Timeout-Einstellungen wirken sich nicht auf die Kosten aus
Ein Timeout ist eine rein clientseitige Einstellung dafür, wie lange Sie zu warten bereit sind. Es hat keinen Einfluss darauf, was eine Anfrage kostet, weiterhin eine Anfrage pro verarbeitetem Element, egal ob Ihr Client die volle Dauer gewartet oder vorzeitig aufgegeben hat.
Wenn Sie Ihr Timeout an die Batch-Größe anpassen und mehrere kleinere Blöcke einer sehr großen Anfrage vorziehen, bleiben große Jobs zuverlässig und lassen sich leicht fortsetzen, falls etwas schiefgeht. Blockbildung und Kontingentstrategie für große Jobs werden in der Dokumentation zu Ratenlimits ausführlicher behandelt.