Retry-Ökonomie: Die Versuchsnummer, ab der sich Wiederholen nicht mehr lohnt

Jeder Scraper wiederholt fehlgeschlagene Anfragen, und die meisten wählen die Anzahl der Wiederholungen auf dieselbe Weise: drei, weil es vernünftig erscheint. Aber Wiederholungen sind nicht kostenlos. Bei Residential Proxies, die nach Gigabyte abgerechnet werden, lädt jede Wiederholung die Seite erneut herunter; bei jedem System kostet sie Zeit und Last auf dem Ziel. Und jede Wiederholung ist in der Regel weniger wahrscheinlich erfolgreich als die vorherige.

Es gibt also einen Punkt, an dem ein weiterer Versuch mehr kostet, als er wert ist. Diese Studie zeigt, wie man diesen Punkt aus den eigenen Logs ermittelt, mit einem durchgerechneten Beispiel und dem Code, um ihn auf die eigenen Daten anzuwenden.

Warum spätere Wiederholungen seltener erfolgreich sind

Wären Fehlschläge reines Pech, hätte jede Wiederholung dieselbe Erfolgschance wie der erste Versuch. In der Praxis ist das nicht so. Eine Anfrage, die einmal fehlschlägt, schlägt eher aus einem bleibenden Grund fehl: eine Seite, die nicht existiert, eine Blockierung dieser Adresse, eine Website, die nicht erreichbar ist, ein Parser, der nie passt. Die Jobs, die Versuch vier erreichen, sind größtenteils die schwierigen Fälle.

Das bedeutet, dass die Erfolgsrate pro Versuch sinkt und die Kosten jedes zusätzlichen Erfolgs mit ihr steigen.

Aus den eigenen Logs messen

Die einzigen Daten, die man braucht, sind für jeden Job die Versuchsnummer, bei der er erfolgreich war, oder ein Vermerk, dass jeder Versuch fehlgeschlagen ist. Die meisten Scraper protokollieren das bereits. Daraus ist die Erfolgsrate von Versuch k der Anteil der Jobs, die Versuch k erreicht haben und dabei erfolgreich waren.

from collections import Counter


def attempt_success_rates(outcomes, max_attempts):
    """Chance that attempt k succeeds, given the job got that far.

    outcomes: per job, the attempt number that succeeded, or None if every
    attempt failed (with max_attempts tries).
    """
    succeeded_at = Counter(o for o in outcomes if o is not None)
    reached = len(outcomes)
    rates = []
    for k in range(1, max_attempts + 1):
        rates.append(succeeded_at[k] / reached if reached else 0.0)
        reached -= succeeded_at[k]
    return rates


def cost_per_success(rates, cap, attempt_cost):
    """Expected cost of one successful job if we stop after `cap` attempts."""
    p_reach, spent, success = 1.0, 0.0, 0.0
    for rate in rates[:cap]:
        spent += p_reach * attempt_cost
        success += p_reach * rate
        p_reach *= 1 - rate
    return spent / success if success else float("inf")


def best_cap(rates, attempt_cost, value_of_success):
    """The last attempt whose expected value still exceeds its cost."""
    cap = 0
    for k, rate in enumerate(rates, start=1):
        if rate * value_of_success > attempt_cost:
            cap = k
    return cap

Drei Funktionen:

• attempt_success_rates wandelt das Log in eine Erfolgsrate pro Versuch um.
• cost_per_success liefert die durchschnittlichen Kosten eines erfolgreichen Jobs, wenn man nach einer bestimmten Anzahl von Versuchen aufhört.
• best_cap findet den letzten Versuch, dessen erwarteter Wert noch höher ist als seine Kosten.

Ein durchgerechnetes Beispiel

Hier ist ein veranschaulichendes Log von 10.000 Jobs, bei denen jeweils sechs Versuche erlaubt sind:

from retry_econ import attempt_success_rates, best_cap, cost_per_success

# Illustrative outcomes for 10,000 jobs, each allowed up to six attempts:
# the attempt that succeeded, or None if all six failed.
outcomes = [1] * 8200 + [2] * 900 + [3] * 260 + [4] * 90 + [5] * 40 + [6] * 20 + [None] * 490
rates = attempt_success_rates(outcomes, max_attempts=6)
print("success rate by attempt:", [round(r, 3) for r in rates])

for cap in range(1, 7):
    print(f"cap {cap}: cost per success {cost_per_success(rates, cap, attempt_cost=1.0):.3f}")

print("best cap if a success is worth 5 attempts:", best_cap(rates, attempt_cost=1.0, value_of_success=5.0))
print("best cap if a success is worth 20 attempts:", best_cap(rates, attempt_cost=1.0, value_of_success=20.0))

success rate by attempt: [0.82, 0.5, 0.289, 0.141, 0.073, 0.039]
cap 1: cost per success 1.220
cap 2: cost per success 1.297
cap 3: cost per success 1.357
cap 4: cost per success 1.412
cap 5: cost per success 1.464
cap 6: cost per success 1.514
best cap if a success is worth 5 attempts: 3
best cap if a success is worth 20 attempts: 5

Drei Dinge fallen auf.

Die Erfolgsrate sinkt schnell. Der erste Versuch ist in 82% der Fälle erfolgreich. Von den Jobs, die Versuch zwei erreichen, ist die Hälfte erfolgreich. Bei Versuch fünf ist es weniger als jeder zehnte.

Jeder zusätzliche Erfolg kostet mehr als der vorherige. Teilt man die Kosten eines Versuchs durch seine Erfolgsrate, erhält man die Kosten eines Erfolgs aus diesem Versuch: etwa 1,2 Versuche beim ersten, 2 beim zweiten, 3,5 beim dritten, 7 beim vierten und über 25 beim sechsten. Die durchschnittlichen Kosten pro Erfolg steigen langsam, wenn man mehr Versuche zulässt, weil jeder zusätzliche Versuch auf weniger Jobs läuft, aber die Grenzkosten steigen steil an.

Die richtige Obergrenze hängt davon ab, was ein Erfolg wert ist. Wenn ein erfolgreicher Datensatz fünf Versuche wert ist, sollte man nach drei aufhören. Wenn er zwanzig wert ist, wie es bei einer Seite sein könnte, die man unbedingt braucht, geht man bis fünf. Es gibt keine einzige richtige Zahl; es gibt eine richtige Zahl für jeden Wert.

Einen Wert für einen Erfolg festlegen

Der Wert eines Erfolgs ist die eine Eingabegröße, die man selbst festlegen muss. Ein paar Möglichkeiten, ihn zu bestimmen:

• Ersetzbare Datensätze, wie eine Preisbeobachtung unter vielen, die täglich erfasst werden, sind einzeln wenig wert. Einen zu verpassen ist in Ordnung; eine niedrige Obergrenze ist richtig.
• Erforderliche Datensätze, wie eine Seite, die einen Datensatz vervollständigt, auf den ein Kunde wartet, sind viel mehr wert. Eine höhere Obergrenze ist sinnvoll.
• Kosten jenseits der Bandbreite zählen ebenfalls: Zeit, Last auf dem Ziel und die Wahrscheinlichkeit, dass das wiederholte Angreifen einer fehlschlagenden Seite eine Blockierung für alles andere nach sich zieht.

Bei einer Web Scraping API, die nur für erfolgreiche Antworten berechnet, verschiebt sich die finanzielle Seite einer Wiederholung zum Anbieter, aber Zeit und Last auf dem Ziel gelten weiterhin. Shifters Web Scraping API berechnet zum Beispiel keine fehlgeschlagenen Anfragen.

Wiederholungen günstiger machen

Die Obergrenze ist nur die halbe Miete. Die andere Hälfte besteht darin, jede Wiederholung erfolgreicher zu machen:

• Vor der Wiederholung warten, und jedes Mal länger warten. Viele Fehlschläge sind vorübergehende Ratenbegrenzungen, die sich von selbst auflösen.
• Etwas ändern, wenn der Fehlschlag das nahelegt. Eine Blockierung einer Adresse kann von einer anderen aus erfolgreich sein; ein Timeout braucht vielleicht ein längeres Timeout, nicht dieselbe Anfrage erneut.
• Nicht wiederholen, was nicht erfolgreich sein kann. Ein 404 oder ein Authentifizierungsfehler schlägt jedes Mal fehl.

Unser Leitfaden zu Retry und Backoff für Web Scraper behandelt diese Techniken im Detail.

Es auf die eigenen Daten anwenden

1. Exportiere für eine Woche von Jobs den Versuch, der erfolgreich war, oder einen Fehlschlag-Marker.
2. Führe attempt_success_rates mit dem aktuellen Maximum aus.
3. Entscheide, was ein Erfolg in Versuchen wert ist.
4. Setze die Obergrenze auf das, was best_cap zurückgibt, pro Job-Typ, wenn diese sich unterscheiden.
5. Überprüfe es monatlich erneut. Die Raten ändern sich, wenn sich Websites und die eigene Einrichtung ändern.

FAQ

Wie oft sollte ein Scraper eine fehlgeschlagene Anfrage wiederholen?

Das hängt davon ab, wie schnell die Erfolgsrate pro Versuch sinkt und was ein erfolgreicher Datensatz wert ist. Messe die Erfolgsrate jedes Versuchs aus den eigenen Logs und höre dann beim letzten Versuch auf, dessen erwarteter Wert noch höher ist als seine Kosten. Bei vielen Jobs sind das zwei bis vier Versuche.

Warum sind Wiederholungen seltener erfolgreich als erste Versuche?

Weil Fehlschläge nicht zufällig sind. Jobs, die einmal fehlschlagen, haben eher ein bleibendes Problem, wie eine fehlende Seite oder eine Blockierung, sodass jeder spätere Versuch aus den schwierigeren Fällen stammt.

Kosten Wiederholungen bei Residential Proxies Geld?

Ja. Residential-Proxy-Traffic wird nach Volumen abgerechnet, sodass jede Wiederholung die Seite erneut herunterlädt. Fehlgeschlagene Versuche, die große Fehlerseiten zurückgeben, kosten ebenfalls Bandbreite.

Sollte ich 404-Fehler wiederholen?

Nein. Eine Seite, die nicht existiert, wird beim nächsten Versuch nicht erscheinen. Wiederhole nur Fehlschläge, die später erfolgreich sein können, wie Timeouts, Ratenbegrenzungen und vorübergehende Serverfehler.

Fazit

Eine Wiederholung lohnt sich, solange die Wahrscheinlichkeit, dass der nächste Versuch erfolgreich ist, multipliziert mit dem Wert eines Erfolgs, nicht unter die Kosten des Versuchs fällt. Die eigenen Logs enthalten bereits die Erfolgsrate jedes Versuchs; miss sie, lege einen Wert für einen Erfolg fest und setze die Obergrenze anhand der Zahlen statt aus Gewohnheit.