Angaben wie "50K Verbindungen" oder "100 gleichzeitige Threads", die Sie haeufig in Proxy-Paketen sehen, beschreiben genau eines: die Anzahl der TCP-Verbindungen, die Sie gleichzeitig offen halten koennen. Dieses Limit bestimmt unmittelbar, wie schnell Sie arbeiten koennen, und die Fehlermeldungen bei Ueberschreitung sind haeufig irrefuehrend.
In diesem Beitrag behandeln wir, was Concurrency ist, wie der richtige Wert berechnet wird und wie eine Limit-Ueberschreitung diagnostiziert wird.
Concurrency und Anfragerate sind nicht dasselbe
Zwei Begriffe werden staendig verwechselt:
Die einfache Form des Little'schen Gesetzes: Anfragerate = Concurrency / durchschnittliche Anfragedauer. Haben Sie 20 gleichzeitige Verbindungen und dauert jede Anfrage im Schnitt 500 ms, koennen Sie 40 Anfragen pro Sekunde senden. Steigt die Anfragedauer auf 2 Sekunden, senden Sie bei gleicher Concurrency nur noch 10 Anfragen pro Sekunde.
Ein langsamer Proxy bremst Ihre Arbeit, ohne die Concurrency zu erhoehen. Deshalb ist die Latenz haeufig ausschlaggebender als das Concurrency-Limit.
Wo wird das Limit durchgesetzt?
Das Concurrency-Limit existiert nicht an einer einzigen Stelle, sondern an mehreren Punkten der Kette zugleich:
200 Threads auf Ihrer Seite zu oeffnen nuetzt nichts, wenn der Anbieter auf 50 begrenzt; der Ueberschuss wartet in der Queue oder laeuft auf einen Fehler.
Anzeichen einer Limit-Ueberschreitung
Wenn Sie das Concurrency-Limit ueberschreiten, erhalten Sie keine klare Meldung "Limit ueberschritten". Typische Anzeichen sind:
Entscheidende Unterscheidung: 429 kommt vom Ziel, der Verbindungs-Reset vom Proxy und EMFILE von Ihrer eigenen Maschine. Alle drei erfordern unterschiedliche Loesungen.
Methode zur Ermittlung der richtigen Concurrency
Statt einer theoretischen Berechnung ist ein experimenteller Ansatz verlaesslicher. Fuehren Sie einen stufenweisen Lasttest durch:
Niedrig beginnen
Senden Sie 200 Anfragen mit 5 gleichzeitigen Verbindungen. Erfassen Sie die durchschnittliche Dauer und die Erfolgsquote.
Verdoppeln
Gehen Sie in Schritten von 10, 20, 40, 80 ... vor. Wiederholen Sie bei jedem Schritt dieselbe Messung.
Den Kipppunkt finden
In dem Moment, in dem der Gesamtdurchsatz (Anfragen/s) nicht mehr steigt und die durchschnittliche Dauer zu wachsen beginnt, sind Sie nahe am tatsaechlichen Limit.
Bei 70 % arbeiten
Verwenden Sie rund 70 % des Kipppunkts als Produktionswert. Diese Reserve schuetzt vor Schwankungen im Tagesverlauf.
Die Durchsatzkurve flacht zwischen 40 und 80 ab, waehrend die Latenz hochschnellt. Ab diesem Punkt fuegt eine hoehere Concurrency nur noch Wartezeit hinzu.
Warum ist der Connection Pool (Keep-Alive) wichtig?
Fuer jede Anfrage einen neuen TCP- und TLS-Handshake durchzufuehren, ist sowohl hinsichtlich Latenz als auch Concurrency teuer. Die Wiederverwendung der Verbindung (Keep-Alive) liefert bei gleicher Concurrency einen deutlich hoeheren Durchsatz:
Die Groesse des Client-Pools darf die vom Anbieter erlaubte Concurrency nicht ueberschreiten. Andernfalls werden ueberzaehlige Verbindungen aufgebaut und sofort geschlossen, und die Kosten des Handshakes sind vergeudet.
Zusammenhang von Concurrency und IP-Anzahl
Die Concurrency zu erhoehen steigert zugleich die Anfragedichte, die aus derselben IP-Adresse stammt. Wendet die Zielseite ein Rate Limit pro IP an, fuehrt eine hoehere Concurrency ueber eine einzige IP unmittelbar zur Sperre. Der richtige Ansatz ist, die Concurrency gemeinsam mit der IP-Anzahl zu skalieren.
Ueberschreiten Sie pro Ziel und pro IP nicht 1-2 gleichzeitige Verbindungen. Wenn Sie 60 gleichzeitige Anfragen senden moechten, benoetigen Sie mindestens 30-60 verschiedene Exit-IPs. Zur Dimensionierung des Pools unser Beitrag zum Proxy-Pool lesen Sie nach.
Zielfreundliches Rate-Management
Ebenso wichtig wie die Concurrency ist die zeitliche Verteilung der Anfragen. Statt 40 Anfragen gleichzeitig zu senden, wirkt es am Ziel natuerlicher und verhindert einen Rueckstau in der Queue, sie mit kleinen Verzoegerungen zu verteilen.
- Jitter hinzufuegen: Eine zufaellige Wartezeit zwischen 150 und 350 ms statt konstanter 200 ms verringert die Bot-Spur.
- Token Bucket verwenden: Ein Token Bucket, der N Anfragen pro Sekunde erzeugt, verhindert ploetzliche Lastspitzen.
- Backoff einsetzen: Senken Sie die Concurrency schrittweise, wenn Sie 429 erhalten, und erhoehen Sie sie langsam wieder, sobald wieder Erfolge eintreten.
- Pro Ziel eine eigene Queue fuehren: Die Verlangsamung einer Website soll die anderen nicht beeintraechtigen.
Typische Limits bei verschiedenen Proxy-Arten
| Unterschied zwischen Shared und Dedicated | Typische Parallelitaet | Begrenzender Faktor |
|---|---|---|
| Datacenter | Hoch - mehrere Hundert | Bandbreite und Rate Limit des Ziels |
| ISP | Mittel bis hoch | Toleranz des Ziels pro IP |
| Residential | Mittel - je nach Tarif | Kontokontingent des Anbieters |
| Mobil | Niedrig | Einzelnes Geraet und Mobilfunkverbindung |
Da Mobile Proxys ueber ein einziges physisches Modem ausgehen, bieten sie naturgemaess eine geringe Concurrency; dafuer besitzen sie den hoechsten Trust Score. Fuer Details unser Beitrag zu Mobile Proxys können Sie nachlesen.
Zusammenfassung
Concurrency ist nicht allein, sondern zusammen mit der Latenz ausschlaggebend fuer die Geschwindigkeit. Der Weg zum richtigen Wert fuehrt ueber einen experimentellen Lasttest: Finden Sie den Punkt, an dem der Durchsatz abflacht und die Latenz hochschnellt, und arbeiten Sie bei 70 % davon. Fixieren Sie den Connection Pool auf diesen Wert, skalieren Sie die Concurrency gemeinsam mit der IP-Anzahl und ziehen Sie sich zurueck, sobald ein 429 kommt. Um die Latenz Ihrer vorhandenen Proxys zu messen, Ping-Test und Proxy-Check können Sie unsere Tools nutzen.