Kurze Antwort
Wie viele parallele Anfragen kann ich über Residential-Proxys ausführen?
So viele, wie jede Zielseite verkraftet: CrawlRelay berechnet Residential-Traffic pro GB (0,50 $/GB ab 50 GB), nicht pro Thread oder Verbindung. Dimensionieren Sie die Nebenläufigkeit mit dem Little-Gesetz: 'Anfragen in Bearbeitung = Seiten pro Sekunde × Sekunden pro Seite', dann begrenzen Sie sie pro Host, starten Sie mit 2 bis 4. Verringern Sie die Anzahl bei 429- oder 503-Antworten. Zahlung in Krypto, ohne KYC.
Nebenläufigkeit auf einen Blick
| Abrechnung | Pro GB Traffic; Threads und Verbindungen werden nicht berechnet |
|---|---|
| Dimensionierungsregel | In Bearbeitung = Durchsatz × Latenz (Little-Gesetz) |
| Ausgangspunkt pro Host | 2–4 parallele Anfragen; 1 mit Verzögerung bei kleinen Seiten |
| Signale zum Verlangsamen | 429, 503, steigende Antwortzeiten, Challenge-Seiten |
| Bandbreitenrechnung | Seiten pro Sekunde × Bytes pro Seite × 3.600 = Bytes pro Stunde |
| Mittlere Residential-Antwortzeit | 0,93 s im Proxy-Netzwerk, 3,21 s auf echten Zielen (Proxyway 2026) |
Wie dimensioniere ich die Nebenläufigkeit basierend auf dem benötigten Durchsatz?
Nutzen Sie das Little-Gesetz: Die Anzahl der Anfragen in Bearbeitung entspricht der gewünschten Rate multipliziert mit der Dauer jeder Anfrage. Proxyway's Proxy Market Research 2026 ermittelte eine mittlere Dauer von 3,21 Sekunden pro Anfrage auf echten Zielen durch Residential-Proxys, planen Sie daher mit 2 bis 4 Sekunden pro Anfrage für echte Seiten und nicht nur mit dem unter einer Sekunde liegenden Netzwerkwert.
| Ziel | Zeit pro Anfrage | Anfragen in Bearbeitung |
|---|---|---|
| 5 Seiten pro Sekunde | 2 s | 10 |
| 20 Seiten pro Sekunde | 2 s | 40 |
| 20 Seiten pro Sekunde | 4 s | 80 |
| 100 Seiten pro Sekunde | 3 s | 300 |
Verteilen Sie diese Anfragen auf Hosts. Vierzig Anfragen in Bearbeitung über 200 Seiten sind schonend; vierzig auf einer kleinen Seite sind ein Lasttest, dem diese nie zugestimmt hat.
Wie viel Bandbreite verbraucht dieser Durchsatz?
Multiplizieren Sie Seiten pro Sekunde mit Bytes pro Seite. Bei 20 HTML-Seiten pro Sekunde und 50 KB pro Seite bewegt der Crawl 1 MB pro Sekunde, was 3,6 GB pro Stunde und ca. 86 GB pro Tag entspricht. Bei 2 MB pro gerenderter Seite wären es 40 MB pro Sekunde.
Multiplizieren Sie das Ergebnis mit dem Preis pro GB Ihres Plans, 0,50 $/GB ab 50 GB bei CrawlRelay, um die stündlichen Kosten zu berechnen. Der Bandbreitenrechner-Guide zeigt typische Seitengrößen nach Seitentyp.
Welche per-Host-Limits sollte ich zuerst einsetzen?
| Ziel | Parallele Anfragen pro Host | Verzögerung zwischen Anfragen | Hinweise |
|---|---|---|---|
| Kleine Seite (Blog, lokaler Laden) | 1 | 2–5 s | Respektieren Sie Crawl-delay in robots.txt, falls vorhanden |
| Mittelseitige Website | 2–4 | 0,5–2 s | Beobachten Sie die Antwortzeiten; reduzieren Sie die Last, wenn sie sich verdoppeln |
| Große Plattform mit CDN | 4–16 | AutoThrottle oder adaptiv | Erhöhen Sie nur, solange die Raten von 429 und 5xx stabil bleiben |
| Öffentliche API | Das dokumentierte Limit | Wie dokumentiert | Verwenden Sie den API-Schlüssel und die Limits, die der Anbieter Ihnen gibt |
Wie passe ich die gleichzeitigen Verbindungen automatisch an?
Verwenden Sie additive Erhöhung und multiplikative Verringerung, die Regel, die TCP zur Staukontrolle nutzt: Fügen Sie nach einer Reihe sauberer Antworten einen Slot hinzu, halbieren Sie das Limit bei 429 oder 503. Der untenstehende Limiter verwaltet ein Limit pro Host, pausiert jede Anfrage an diesen Host für die Retry-After Verzögerung, versucht einmal neu und überschreitet niemals eine von Ihnen gesetzte Obergrenze. Netzwerkfehler werden als Werte zurückgemeldet, sodass ein Timeout den Batch nicht anhält.
import asyncio
import random
from urllib.parse import urlsplit
import httpx
PROXY = "http://USERNAME-country-us:[email protected]:7777"
class AdaptiveLimit:
"""One per host: +1 slot after 20 clean responses, halve on 429/503, pause for Retry-After."""
def __init__(self, start=2, low=1, high=16):
self.limit, self.low, self.high = start, low, high
self.in_flight, self.clean = 0, 0
self.pause_until = 0.0
self.cond = asyncio.Condition()
async def __aenter__(self):
loop = asyncio.get_running_loop()
while True:
async with self.cond:
await self.cond.wait_for(lambda: self.in_flight < self.limit)
delay = self.pause_until - loop.time()
if delay <= 0:
self.in_flight += 1
return self
await asyncio.sleep(delay) # the host asked for a pause: wait outside the lock
async def __aexit__(self, *exc):
async with self.cond:
self.in_flight -= 1
self.cond.notify_all()
def record(self, status, retry_after=None):
if status in (429, 503):
self.limit, self.clean = max(self.low, self.limit // 2), 0
wait = int(retry_after) if retry_after and retry_after.isdigit() else 5 + random.random()
now = asyncio.get_running_loop().time()
self.pause_until = max(self.pause_until, now + wait)
elif status < 400:
self.clean += 1
if self.clean >= 20 and self.limit < self.high:
self.limit, self.clean = self.limit + 1, 0
gates = {}
def gate_for(url):
host = urlsplit(url).hostname
if host not in gates:
gates[host] = AdaptiveLimit()
return gates[host]
async def fetch(client, url, attempts=2):
gate = gate_for(url)
status = None
for _ in range(attempts):
try:
async with gate:
r = await client.get(url)
except httpx.HTTPError as exc:
return "error: %s" % type(exc).__name__
status = r.status_code
gate.record(status, r.headers.get("Retry-After"))
if status not in (429, 503):
break # the retry, if any, waits for the host's pause in __aenter__
return status
async def main(urls):
timeout = httpx.Timeout(30.0, connect=10.0)
async with httpx.AsyncClient(proxy=PROXY, timeout=timeout) as client:
print(await asyncio.gather(*(fetch(client, u) for u in urls)))
print({host: gate.limit for host, gate in gates.items()})
asyncio.run(main(["https://example.com/"] * 10))Was verlangsamt einen proxied Crawl außer dem Ziel?
- TLS-Handshakes. Eine neue Verbindung pro Anfrage, die Sie für jede neue IP benötigen, fügt bei jeder Anfrage einen Handshake mit der Seite hinzu. Halten Sie eine Sticky Session mit Keep-Alive für Seiten einer Site, wenn IP-Diversität nicht wichtig ist.
- Langsame Ausgänge. Residential- und mobile 4G-Proxys sind echte Heim- und Mobilfunkverbindungen. Verwenden Sie Timeouts und versuchen Sie einen neuen Verbindungsaufbau anstelle von Warteschleifen.
- Enges Targeting. Eine kleine Stadt oder eine einzige ASN hat weniger Ausgänge als ein ganzes Land. Zielen Sie eng, nur dort wo sich die Daten ändern.
- Rendering. Ein Headless-Browser verbraucht viel mehr CPU, Arbeitsspeicher und Traffic pro Seite als ein HTTP-Client. Rendern Sie nur Seiten, die JavaScript benötigen.
- DNS. Mit
socks5h://oder dem HTTP-Port löst sich DNS am Exit auf; ein lokaler Resolver-Cache für Ziel-Hosts ist nicht nötig.
Fragen zur gleichzeitigen Verarbeitung
Beschränkt CrawlRelay die Anzahl der Threads oder Verbindungen?
Pläne werden pro GB Traffic abgerechnet, nicht pro Thread, Verbindung oder Anfrage, und die veröffentlichten Pläne geben keine Threadzahl vor. Die praktischen Limits sind die Belastbarkeit jedes Ziels und Ihre eigene Maschine. Wenn Sie einen sehr großen Crawl planen, schreiben Sie zuerst an [email protected], damit wir die Abdeckung Ihrer Zielsetzung prüfen können.
Warum wurde mein Crawl langsamer, als ich mehr Threads hinzufügte?
Normalerweise, weil das Ziel begann, Sie zu drosseln: Antwortzeiten steigen, 429- oder 503-Antworten erscheinen und Wiederholungen erhöhen die Last. Die andere häufige Ursache ist, dass Ihre eigene Maschine wegen CPU- oder Socketmangel ausbremst, besonders mit Headless-Browsern. Messen Sie Latenz und Fehlerraten pro Host, bevor Sie Threads erhöhen.
Ist eine Verbindung pro Anfrage langsamer als Keep-Alive?
Ja, um eine TCP- und TLS-Handshake pro Anfrage, typischerweise ein paar hundert Millisekunden über Residential-Proxys. Das ist der Preis für eine neue IP bei jeder Anfrage. Für viele Seiten einer Site, bei denen die IP keine Rolle spielt, ist eine Sticky Session mit Keep-Alive schneller und spart Traffic.
Wie respektiere ich crawl-delay in robots.txt bei einem konkurrierenden Crawler?
Parsen Sie robots.txt einmal pro Host, cachen Sie es bis zu 24 Stunden, wie RFC 9309 empfiehlt, und interpretieren Sie einen Wert Crawl-delay als minimale Pause pro Host zwischen Anfragen bei einer Konkurrenz von 1. Pythons urllib.robotparser macht das über crawl_delay() zugänglich.
Skalieren durch Abrechnung pro GB
0,50 $/GB von 50 GB bis 1 TB, Traffic, der nie abläuft.