Wie man Anfragevolumen und Parallelität bei Residential Proxies plant

Die meisten Fragen zur Kapazität kommen rückwärts an. Jemand fragt, wie viele Threads laufen sollen oder wie viel Bandbreite zu kaufen ist, obwohl keines von beidem bekannt sein kann, bevor man die eigentliche Anforderung übersetzt hat, die üblicherweise so aussieht wie “fünfzigtausend Produktdatensätze, täglich aktualisiert, bereit bis 08:00”. Dieser Satz enthält alles, was man braucht. Hier ist, wie man ihn in Anfragevolumen, Nebenläufigkeit und Plangröße umwandelt, und wo die Beschränkung wirklich greift.

Beginnen Sie bei Datensätzen, nicht bei Anfragen

Die erste Umrechnung ist diejenige, die die meisten überspringen, und genau dort gehen Schätzungen um ein Vielfaches daneben.

Ein Datensatz entspricht selten einer Anfrage. Ein Produktdatensatz benötigt vielleicht eine Listing-Seite plus eine Detailseite, also zwei. Wenn das Listing paginiert und Sie jedes Element benötigen, kommen die Paginierungsanfragen hinzu, verteilt auf die Datensätze, die sie liefern. Wenn eine Detailseite ihre Daten über einen zweiten Aufruf lädt, ist das ein weiterer. Und wenn Sie Seiten in einem Browser rendern statt Daten-Endpunkte abzurufen, wird aus einer logischen Anfrage schnell ein Dutzend Asset-Abrufe, was für die Bandbreite enorm ins Gewicht fällt, selbst wenn sich die logische Anzahl nicht ändert.

Schreiben Sie es also explizit auf:

requests_per_record = detail_pages + (listing_pages / records_per_listing) + extra_calls

Bei fünfzigtausend Datensätzen mit sagen wir 1,2 Anfragen pro Datensatz sind das 60.000 Anfragen pro Lauf. Dann fügen Sie einen Ausfallpuffer hinzu, denn Ihre validierte Erfolgsrate liegt nicht bei 100 %. Bei 90 % benötigen Sie etwa 67.000 Versuche, um 60.000 Erfolge zu erzielen, und wenn Sie zusätzlich vorübergehende Fehler wiederholen, liegt die tatsächliche Zahl noch etwas höher. Gegen Erfolge statt gegen Versuche zu planen, ist der zweithäufigste Schätzfehler.

Die Nebenläufigkeit ergibt sich aus Rate und Latenz

Nun kommt der Teil, der überrascht. Nebenläufigkeit ist keine Zahl, die man frei wählt; sie ergibt sich daraus, wie schnell Sie sein müssen und wie lange jede Anfrage dauert.

Wenn Sie 67.000 Anfragen in einem Vier-Stunden-Fenster abschließen müssen, sind das etwa 4,7 Anfragen pro Sekunde im Dauerbetrieb. Residential-Anfragen sind langsamer als direkte, nehmen Sie also im Schnitt zwei Sekunden pro Anfrage von Anfang bis Ende an. Die Anzahl gleichzeitig laufender Anfragen ergibt sich einfach aus Rate multipliziert mit Latenz:

concurrency = requests_per_second x average_latency_seconds
            = 4.7 x 2
            ~ 10 concurrent requests

Diese Beziehung sollte man sich verinnerlichen, denn sie erklärt zwei Dinge gleichzeitig. Langsamere Ziele benötigen mehr Nebenläufigkeit für denselben Durchsatz, weshalb ein Ziel, das sich unauffällig verschlechtert, einen Zeitplan aushungern kann, ohne dass Fehler auftreten. Und eine Erhöhung der Nebenläufigkeit erhöht den Durchsatz nicht, wenn das Ziel das ist, was Sie ausbremst; sie erhöht nur die Anzahl der wartenden Anfragen.

Rechnen Sie es auch andersherum. Wenn Sie die Nebenläufigkeit auf 10 begrenzen und die Latenz von zwei auf fünf Sekunden ansteigt, fällt Ihr Durchsatz von 5 Anfragen pro Sekunde auf 2, und aus einem Vier-Stunden-Job wird ein Zehn-Stunden-Job. Den Zeitplan mit Puffer statt am Limit zu bauen, verhindert, dass eine Latenzverschiebung zu einer verpassten Frist wird.

Die Beschränkung ist das Ziel, nicht Ihre Maschine

Hier trifft die Planung auf die Realität. Die Nebenläufigkeit, die Ihre Infrastruktur bewältigen kann, ist fast nie die bindende Grenze. Was bindet, ist das, was das Ziel toleriert.

Ratenbegrenzungen werden pro IP durchgesetzt und zunehmend auch pro Ziel in der Summe. Ein Pool erlaubt es Ihnen, die Last pro IP zu verteilen, aber die Gesamtmenge, die bei einem Ursprung ankommt, ist weiterhin sichtbar, weshalb die Zahl, gegen die geplant werden muss, das ist, was die Seite akzeptiert, und nicht, was Ihre Worker ausgeben können. Die Mechanik der Taktung findet sich in rate limiting and throttling, und die anschließende Verteilungsfrage, wie viel Streuung Ihr Volumen benötigt, wird in how many proxy IPs you actually need durchgearbeitet.

Praktisch bedeutet das, dass Ihr Plan eine Nebenläufigkeitsobergrenze pro Ziel und eine Rate pro Ziel enthalten sollte, nicht eine globale Einstellung. Fünfzig Ziele mit jeweils moderater Nebenläufigkeit sind ein völlig anderes Szenario als dasselbe Gesamtvolumen auf eine Seite gerichtet, und nur das zweite bringt Ihnen eine Sperre ein.

Bandbreite ist die Zahl, die Sie tatsächlich kaufen

Da Residential-Proxys nach übertragenen Daten abgerechnet werden, ergibt sich die Plangröße aus Bytes und nicht aus Anfragen oder Adressen.

monthly_bandwidth = attempts_per_run x runs_per_month x average_bytes_per_response

Die Variable, die dominiert, ist die letzte, und sie liegt vollständig in Ihrer Hand. Eine JSON-Antwort oder eine schlanke HTML-Seite umfasst zehn bis wenige zehn Kilobyte; eine vollständig gerenderte Seite mit Bildern, Schriften und Drittanbieter-Skripten umfasst mehrere Megabyte. Bei 60.000 täglichen Anfragen kommen 50-KB-Antworten auf etwa 90 GB im Monat, während 2-MB-gerenderte Seiten auf etwa 3,6 TB kommen, bei derselben logischen Arbeitslast. Das ist der Unterschied zwischen einem bescheidenen Plan und einem Enterprise-Plan, und er wird davon entschieden, ob Sie Daten abrufen oder Seiten rendern, siehe when you need a headless browser und cutting bandwidth costs.

Nehmen Sie diese Optimierung vor, bevor Sie den Plan dimensionieren, denn sie bringt Sie häufig eine Stufe herunter. Die ausführlichere Prognosemethode findet sich in estimating monthly bandwidth, und die Entscheidungen auf Produktebene in choosing the right plan.

Zeitplanung: Verteilen schlägt Bündeln

Zwei Jobs mit identischem Tagesvolumen können sich völlig unterschiedlich verhalten, je nachdem, wann sie laufen.

Alles in ein einstündiges Fenster zu pressen, vervielfacht Ihre momentane Rate gegenüber jedem Ziel gleichzeitig, was genau die Form ist, die Abwehrmechanismen auslöst. Dieselbe Arbeit über das verfügbare Fenster zu verteilen, senkt die Rate pro Ziel kostenlos, und es gibt Fehlern auch Raum, später im Lauf wiederholt zu werden, statt sich am Ende anzuhäufen.

Anforderungen an die Aktualität setzen die Beschränkung. Wenn Daten bis 08:00 aktuell sein müssen, müssen Sie sie vorher sammeln, aber das ist eine Frist und keine Anweisung, um 07:00 zu starten. Wo der Zeitplan es zulässt, ist es strikt besser, über das gesamte Fenster zu verteilen und die volatilsten Quellen früh zu priorisieren.

Mit einem Pilotlauf validieren, bevor Sie sich festlegen

Jede Zahl oben ist eine Hypothese, bis Sie die beiden angenommenen Variablen messen: die tatsächliche durchschnittliche Latenz auf Ihren echten Zielen über Residential-Exits und die tatsächlichen Bytes pro Antwort, nachdem Ihre Abrufstrategie feststeht. Beide lassen sich leicht bei einem kleinen Lauf messen, und beide verändern den Plan erheblich.

Führen Sie einen Pilotlauf mit vielleicht fünf Prozent des vorgesehenen Volumens durch, erfassen Sie validierte Erfolgsrate, Latenzperzentile und Bytes pro Anfrage pro Ziel, und rechnen Sie dann neu. Erwarten Sie, dass das Ergebnis in beide Richtungen von Ihrer Schätzung abweicht. Die Messmethode findet sich in testing speed, success rate and location accuracy, und die laufenden Versionen derselben Zahlen sind die Kennzahlen in proxy KPIs.

Eine durchgerechnete Zusammenfassung

Anforderung: 50.000 Datensätze täglich, bereit bis 08:00, Sammelfenster 04:00 bis 08:00.

Anfragen pro Datensatz 1,2, was 60.000 Erfolge ergibt. Bei 90 % validierter Erfolgsrate etwa 67.000 Versuche. Über vier Stunden sind das 4,7 pro Sekunde. Bei durchschnittlich zwei Sekunden Latenz etwa 10 gleichzeitige Anfragen, die Sie dann auf Ziele aufteilen, statt sie auf eines zu richten. Bei durchschnittlich 80 KB pro Antwort etwa 5,4 GB pro Lauf und rund 160 GB im Monat. Fügen Sie sowohl bei Nebenläufigkeit als auch bei Bandbreite Puffer hinzu, denn Latenz driftet und Erfolgsraten sinken, und leiten Sie nach dem Pilotlauf neu ab.

Das Fazit

Planen Sie rückwärts: Datensätze zu Anfragen, Anfragen zu Versuchen nach Ausfallpuffer, Versuche über das Fenster zu einer Rate, Rate mal Latenz zu Nebenläufigkeit, und Versuche mal Antwortgröße zu Bandbreite. Begrenzen Sie Nebenläufigkeit und Rate pro Ziel statt global, denn die bindende Beschränkung ist das, was jede Seite toleriert, und nicht das, was Ihre Infrastruktur produzieren kann. Optimieren Sie, was Sie abrufen, bevor Sie den Plan dimensionieren, denn Rendern gegenüber reinem Datenabruf kann die Bandbreitenantwort um zwei Größenordnungen verändern. Verteilen Sie die Arbeit über das verfügbare Fenster, statt sie zu bündeln. Führen Sie dann einen Pilotlauf durch, denn Latenz und Bytes pro Antwort sind die beiden Annahmen, die es sich lohnt, durch Messungen zu ersetzen, bevor Sie sich auf einen Plan festlegen.

Die Kapazität selbst stammt aus residential proxies, wo die Nebenläufigkeit nicht die Beschränkung ist, auf die der Plan dimensioniert wird, mit per-GB pricing, sodass die von Ihnen abgeleitete Bandbreitenzahl die Zahl ist, die Sie tatsächlich kaufen.