Ohne KYC — keine ID, kein Selfie, keine Dokumente. Mit Krypto bezahlen: BTC, USDT, USDC, ETH, SOL, LTC
Sprache: Deutsch
Jetzt starten

Dokumentation · Nebenläufigkeit · Durchsatz · Höflichkeit

Nebenläufigkeit und Durchsatz durch Residential-Proxys

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.

Zuletzt aktualisiert: · 6 Min. Lesezeit

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

AbrechnungPro GB Traffic; Threads und Verbindungen werden nicht berechnet
DimensionierungsregelIn Bearbeitung = Durchsatz × Latenz (Little-Gesetz)
Ausgangspunkt pro Host2–4 parallele Anfragen; 1 mit Verzögerung bei kleinen Seiten
Signale zum Verlangsamen429, 503, steigende Antwortzeiten, Challenge-Seiten
BandbreitenrechnungSeiten pro Sekunde × Bytes pro Seite × 3.600 = Bytes pro Stunde
Mittlere Residential-Antwortzeit0,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.

ZielZeit pro AnfrageAnfragen in Bearbeitung
5 Seiten pro Sekunde2 s10
20 Seiten pro Sekunde2 s40
20 Seiten pro Sekunde4 s80
100 Seiten pro Sekunde3 s300

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?

ZielParallele Anfragen pro HostVerzögerung zwischen AnfragenHinweise
Kleine Seite (Blog, lokaler Laden)12–5 sRespektieren Sie Crawl-delay in robots.txt, falls vorhanden
Mittelseitige Website2–40,5–2 sBeobachten Sie die Antwortzeiten; reduzieren Sie die Last, wenn sie sich verdoppeln
Große Plattform mit CDN4–16AutoThrottle oder adaptivErhöhen Sie nur, solange die Raten von 429 und 5xx stabil bleiben
Öffentliche APIDas dokumentierte LimitWie dokumentiertVerwenden 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
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.

Ab 0,50 $/GB · ohne KYC

Jetzt starten