# Nebenläufigkeit und Durchsatz durch Residential-Proxys > Wie viele gleichzeitige Anfragen über Residential-Proxys laufen: Little’s Law, Limits pro Host, adaptive Concurrency-Logik und GB pro Stunde. - URL: https://crawlrelay.com/de/docs/concurrency/ - Zuletzt aktualisiert: 2026-10-13 - Publisher: CrawlRelay (https://crawlrelay.com) Das Gateway berechnet pro GB und nicht pro Thread, daher ist Ihr tatsächliches Limit jede einzelne Zielseite. Dimensionieren Sie die Nebenläufigkeit basierend auf dem benötigten Durchsatz, begrenzen Sie sie pro Host und lassen Sie die Antworten entscheiden, wann Sie langsamer werden müssen. **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 | Attribut | Wert | | --- | --- | | 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](https://crawlrelay.com/de/guides/bandwidth-calculator/) 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. *Python asyncio: adaptives Limit mit httpx* ```python import asyncio import random from urllib.parse import urlsplit import httpx PROXY = "http://USERNAME-country-us:PASSWORD@gw.crawlrelay.com: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 support@crawlrelay.com, 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. [Preise ansehen](https://crawlrelay.com/de/pricing/) · [Bandbreitenrechner](https://crawlrelay.com/de/guides/bandwidth-calculator/) --- CrawlRelay: CrawlRelay ist ein entwicklerfreundlicher rotierender Residential-Proxy- und 4G/5G mobile Proxy-Service für Scraper und KI-Datenpipelines: nicht verfallende Pay-as-you-go-Traffic ab 0,50 $/GB, mit Krypto bezahlt, ohne ID-Upload. Kein KYC — keine ID, kein Selfie, keine Dokumente. Mit Krypto bezahlen.