Residential Proxy Lasttests: So führen Sie Stresstests vor dem Produktionseinsatz durch

Bevor eine Collection-Pipeline in Produktion geht, fragt sich zu Recht jemand, ob sie bei voller Auslastung standhält. Der Instinkt sagt, einen Lasttest durchzuführen, und der Instinkt ist richtig, aber Proxy-Lasttests haben eine Einschränkung, die gewöhnliche Lasttests nicht haben: Das, wogegen man Traffic schickt, gehört meist jemand anderem.

Diese einzelne Tatsache verändert die gesamte Übung. Man testet nicht, ob ein System die eigene Last verkraftet, sondern charakterisiert das Verhalten der eigenen Pipeline und findet die eigene Obergrenze, ohne einen unangekündigten Stresstest gegen einen Dritten durchzuführen. So geht man dabei richtig vor.

Was tatsächlich getestet wird

Trennen Sie die vier Fragen, denn sie erfordern unterschiedliche Tests, und nur eine davon betrifft ein reales Ziel.

Die Kapazität der eigenen Pipeline. Wie viele gleichzeitige Requests Ihre Worker, das Connection-Handling, das Parsing und die Speicherung verkraften, bevor etwas in die Sättigung geht. Dies ist ein Test Ihres Codes und Ihrer Infrastruktur und kann durchgeführt werden, ohne die Seite von irgendjemand anderem zu berühren.

Verhalten des Proxy-Pfads unter Nebenläufigkeit. Wie sich Latenz und Erfolgsrate verändern, wenn Sie die Anzahl gleichzeitiger Requests durch das Gateway erhöhen. Auch dies ist größtenteils unabhängig von einem konkreten Ziel.

Die Toleranz des Ziels. Welches Tempo eine bestimmte Seite akzeptiert, bevor sie drosselt oder Sie mit einer Challenge konfrontiert. Dies ist derjenige Punkt, dem man sich vorsichtig und schrittweise nähern muss, nicht mit einem Lastgenerator.

End-to-End-Durchsatz. Was all das Vorgenannte zusammen ergibt, also die Zahl, von der Ihr Zeitplan tatsächlich abhängt.

Werden diese vermischt, entsteht das klassische schlechte Ergebnis: ein „Lasttest“, der auf ein Ziel einprügelt, blockiert wird und Ihnen nichts sagt, außer dass Sie blockiert werden können.

Zuerst gegen etwas Eigenes testen

Stellen Sie ein Ziel auf, das Sie selbst kontrollieren und das eine Antwort realistischer Größe liefert, und richten Sie die Pipeline über die Proxies darauf aus. Dies isoliert alles außer dem Dritten.

Dabei lernt man überraschend viel. Ob Ihr Worker-Pool tatsächlich die konfigurierte Nebenläufigkeit erreicht. Ob das Connection-Handling tut, was Sie annehmen, denn gepoolte Verbindungen verhalten sich durch ein Gateway anders, gemäß IP not rotating. Wo Ihr Parsing oder Ihre Speicherung zum Engpass wird. Und welche Latenzverteilung der Proxy-Pfad hinzufügt, ohne die Eigenvariabilität eines Ziels darin vermischt zu haben.

Verwenden Sie realistische Payload-Größen. Ein Test gegen einen winzigen Endpunkt überschätzt Ihren Durchsatz stark, da sowohl Bandbreite als auch Parsing mit der Antwortgröße skalieren und residentielle Latenz bei unterschiedlichen Payload-Größen unterschiedlich stark dominiert.

Die richtigen Dinge messen

Durchsatz allein ist eine schlechte Zusammenfassung. Fünf Messgrößen machen einen Lasttest interpretierbar.

Validierte Erfolgsrate, nicht HTTP-Erfolg. Ein Test, der 100% Erfolg meldet, während er Challenge-Seiten zurückgibt, misst das Falsche, gemäß detecting blocked or fake content.

Latenz-Perzentile, konkret p50, p95 und p99. Residentielle Latenz hat eine breite Verteilung, sodass ein Mittelwert den Schwanz verbirgt, der tatsächlich bestimmt, ob ein zeitlich begrenzter Job fertig wird.

Durchsatz als Funktion der Nebenläufigkeit, geplottet statt an einem einzigen Punkt gemessen. Das interessante Merkmal ist, wo die Kurve abflacht, denn darüber hinaus fügen Sie laufende Requests hinzu, ohne zusätzliche Abschlüsse zu erhalten.

Verteilung der Fehlerklassen, denn die Mischung verrät Ihnen, was Sie limitiert. Timeouts weisen in eine Richtung, Rate-Signale in eine andere und Challenges wieder in eine andere, gemäß common residential proxy errors.

Bytes pro Request, da dies die Kosten bei Produktionsvolumen bestimmt und jetzt leicht zu messen ist, später aber teuer herauszufinden, gemäß estimating monthly bandwidth.

Hochfahren, nicht spiken

Erhöhen Sie die Nebenläufigkeit in Schritten, halten Sie jeden Schritt lange genug, damit sich die Zahlen einpendeln, und zeichnen Sie bei jedem Level den vollständigen Satz an Messwerten auf. Ein Spike-Test sagt hier fast nichts Brauchbares aus, denn der dadurch entstehende Fehler ist nicht von der Reaktion eines Ziels auf einen Burst zu unterscheiden.

Die Form, nach der Sie suchen, ist der Punkt, an dem der Durchsatz aufhört, mit der Nebenläufigkeit zu steigen, und an dem die p95-Latenz stark zu steigen beginnt. Diese beiden fallen meist zusammen und markieren Ihre praktische Obergrenze. Führen Sie Ihren Produktions-Job irgendwo darunter aus, nicht direkt daran, denn die Obergrenze verschiebt sich mit dem Verhalten des Ziels, der Tageszeit und den Pool-Bedingungen.

for concurrency in [5, 10, 20, 40, 80]:
    stats = run_step(concurrency, duration_seconds=180)   # hold, then record
    print(concurrency, stats.validated_success, stats.p50,
          stats.p95, stats.rps, stats.bytes_per_req, stats.error_mix)
    if stats.validated_success < 0.9 or stats.p95 > LATENCY_BUDGET:
        break                                              # found the knee

Vorsichtige Kalibrierung gegen ein reales Ziel

Irgendwann müssen Sie wissen, was Ihre tatsächlichen Quellen tolerieren, und das lässt sich nicht anhand eines Mocks lernen. Machen Sie es als Kalibrierung, nicht als Lasttest.

Beginnen Sie deutlich unter Ihrer beabsichtigten Rate und steigern Sie langsam, wobei Sie die validierte Erfolgsrate beobachten statt Statuscodes. Stoppen Sie die Steigerung beim ersten Anzeichen von Verschlechterung, statt bis zum Versagen zu treiben, denn das Ziel ist es, ein nachhaltiges Tempo zu finden, keinen Bruchpunkt. Verteilen Sie die Kalibrierung über einen längeren Zeitraum, als es sich nötig anfühlt, denn Drosselung wird oft über rollierende Zeitfenster angewendet, und ein kurzer Burst kann bestehen, während eine anhaltende Rate es nicht tut.

Respektieren Sie, was das Ziel Ihnen mitteilt. Ein 429 oder ein Retry-After ist eine direkte Anweisung, und die richtige Reaktion ist, langsamer zu werden, statt Adressen zu rotieren, um das Tempo zu halten, was der Unterschied ist bei rate limiting and throttling.

Und bewahren Sie die Verhältnismäßigkeit: Ihr Kalibrierungs-Traffic sollte ein Rundungsfehler gegenüber der normalen Last der Seite sein. Eine gezielte Stresstest-Belastung der Infrastruktur eines Dritten ist keine harmlose technische Übung und kann je nach Ausmaß und Absicht zur Einmischung werden. Wenn Sie die Grenzen eines Partners genau kennen müssen, fragen Sie ihn.

Die Ergebnisse interpretieren

Übersetzen Sie die Kurve in die zwei Zahlen, die Ihre Produktionskonfiguration braucht: eine Nebenläufigkeitsobergrenze pro Ziel und eine Rate pro Ziel, beide unterhalb des Knies mit Spielraum angesetzt.

Prüfen Sie das Ganze dann gegen Ihren Zeitplan auf Plausibilität. Nebenläufigkeit ergibt sich aus Rate und Latenz, wenn also Ihre gemessene p50-Latenz höher ist als angenommen, steigt die für eine bestimmte Frist benötigte Nebenläufigkeit entsprechend, was die Rechnung in planning request volume and concurrency ist.

Behandeln Sie die Ergebnisse schließlich als verderblich. Ziel-Abwehrmechanismen ändern sich, Pool-Bedingungen variieren je nach Stunde und Markt, und eine in einer ruhigen Woche gemessene Zahl hält einer Spitzenzeit nicht stand. Führen Sie die Kalibrierung regelmäßig erneut durch, und noch wichtiger: Führen Sie dieselben Messungen kontinuierlich in der Produktion durch, damit die Obergrenze beobachtet statt angenommen wird, gemäß monitoring proxy health at scale.

Fazit

Proxy-Lasttests sind Kapazitätscharakterisierung, kein Angriff auf einen Dritten. Trennen Sie die vier Fragen und testen Sie die ersten beiden gegen eigene Infrastruktur mit realistischen Payload-Größen, was die tatsächlichen Engpässe Ihrer Pipeline von der Variabilität eines Ziels isoliert. Messen Sie validierte Erfolgsrate, Latenz-Perzentile, Durchsatz gegenüber Nebenläufigkeit, die Verteilung der Fehlerklassen und Bytes pro Request, fahren Sie dann in Schritten hoch und suchen Sie das Knie, an dem der Durchsatz abflacht und p95 ansteigt. Kalibrieren Sie gegen reale Ziele langsam und stoppen Sie beim ersten Anzeichen von Verschlechterung, statt bis zum Versagen zu treiben, und respektieren Sie Rate-Signale, indem Sie langsamer werden statt zu rotieren. Setzen Sie Produktionsobergrenzen unterhalb des Knies, leiten Sie Ihre Nebenläufigkeit erneut aus der gemessenen Latenz ab und messen Sie weiterhin in der Produktion, denn die Obergrenze verschiebt sich.

Der getestete Pfad sind residential proxies, bei denen Nebenläufigkeit und Geografie pro Request eingestellte Parameter sind statt Plan-Einstellungen, abgerechnet per GB, sodass ein gut abgegrenzter Lasttest ungefähr das kostet, was seine Bandbreite kostet.