# Concorrenza e throughput tramite proxy residenziali

> Quante richieste concorrenti eseguire attraverso proxy residenziali: legge di Little, limiti per host, codice di concorrenza adattiva e GB per ora.

- URL: https://crawlrelay.com/it/docs/concurrency/
- Ultimo aggiornamento: 2026-10-13
- Publisher: CrawlRelay (https://crawlrelay.com)

Il gateway addebita per GB, non per thread, quindi il tuo vero limite è ogni sito target. Dimensiona la concorrenza in base al throughput necessario, imposta un limite per host e lascia che le risposte ti indichino quando rallentare.

**Risposta rapida — Quante richieste concorrenti posso eseguire tramite proxy residenziali?**

Tante quante ogni sito target tollera: **CrawlRelay** fattura il traffico residenziale per GB (0,50 USD/GB da 50 GB), non per thread o connessione. Dimensiona la concorrenza con la legge di Little, richieste in volo = pagine al secondo × secondi per pagina, poi limita per host, partendo da 2 a 4. Abbassalo quando appaiono risposte 429 o 503. Pagato in crypto, senza KYC.

## Concorrenza a colpo d'occhio

| Attributo | Valore |
| --- | --- |
| Fatturazione | Per GB di traffico; thread e connessioni non sono fatturati |
| Regola di dimensionamento | In volo = throughput × latenza (legge di Little) |
| Punto di partenza per host | 2–4 richieste parallele; 1 con ritardo per siti piccoli |
| Segnali per rallentare | 429, 503, aumento dei tempi di risposta, pagine con challenge |
| Calcolo della larghezza di banda | Pagine al secondo × byte per pagina × 3.600 = byte all'ora |
| Tempo di risposta mediano residenziale | 0,93 s sulla rete proxy, 3,21 s sui target reali (Proxyway 2026) |

## Come dimensiono la concorrenza in base al throughput necessario?

Usa la legge di Little: il numero di richieste in volo è pari alla velocità desiderata moltiplicata per il tempo che impiega ogni richiesta. Proxyway Proxy Market Research 2026 ha misurato una mediana di 3,21 secondi per richiesta su target reali tramite proxy residenziali, quindi pianifica con 2-4 secondi per siti reali, non con il dato sub-secondo della sola rete.

| Obiettivo | Tempo per richiesta | Richieste in volo |
| --- | --- | --- |
| 5 pagine al secondo | 2 s | 10 |
| 20 pagine al secondo | 2 s | 40 |
| 20 pagine al secondo | 4 s | 80 |
| 100 pagine al secondo | 3 s | 300 |

Poi distribuisci queste richieste sugli host. Quaranta richieste in volo su 200 siti è una pressione ridotta; quaranta su un solo sito piccolo è un test di carico a cui non ha mai acconsentito.

## Quanta larghezza di banda utilizza quel throughput?

Moltiplica pagine al secondo per byte per pagina. A 20 pagine HTML al secondo e 50 KB per pagina, il crawl consuma 1 MB al secondo, cioè 3,6 GB all'ora e circa 86 GB al giorno. A 2 MB per pagina renderizzata, la stessa velocità porterebbe a 40 MB al secondo.

Moltiplica il risultato per il prezzo per GB del tuo piano, 0,50 USD/GB da 50 GB a CrawlRelay, per ottenere il costo orario. La [guida al calcolatore di larghezza di banda](https://crawlrelay.com/it/guides/bandwidth-calculator/) fornisce pesi tipici delle pagine per tipo di pagina.

## Quali limiti per host dovrei impostare inizialmente?

| Target | Richieste parallele per host | Ritardo tra le richieste | Note |
| --- | --- | --- | --- |
| Sito piccolo (blog, negozio locale) | 1 | 2–5 s | Rispetta `Crawl-delay` in robots.txt se presente |
| Sito medio | 2–4 | 0,5–2 s | Monitora i tempi di risposta; rallenta quando raddoppiano |
| Grande piattaforma con CDN | 4–16 | AutoThrottle o adattivo | Aumenta solo mentre i tassi 429 e 5xx restano costanti |
| API pubblica | Il limite documentato | Come documentato | Usa la API key e i limiti forniti dal provider |

## Come faccio ad adattare automaticamente la concorrenza?

Usa incremento additivo e decremento moltiplicativo, la regola TCP per la congestione: aggiungi uno slot dopo una serie di risposte pulite, dimezza il limite su 429 o 503. Il limitatore qui sotto mantiene un limite per host, mette in pausa ogni richiesta a quell'host per il ritardo `Retry-After`, ritenta una volta e non supera mai un tetto impostato. Gli errori di rete tornano come valori, quindi un timeout non blocca l'intero batch.

*Python asyncio: limite adattivo con 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))
```

## Cosa rallenta una crawl proxata oltre al target?

- **Handshake TLS.** Una nuova connessione per richiesta, necessaria per un nuovo IP ogni volta, aggiunge un handshake con il sito ogni volta. Mantieni una sessione sticky con keep-alive per pagine dello stesso sito quando la diversità IP non conta.
- **Uscite lente.** Le uscite residenziali e mobili sono vere linee domestiche e cellulari. Usa timeout e ritenta con una nuova connessione invece di aspettare.
- **Targeting ristretto.** Una piccola città o un singolo ASN hanno meno uscite di un paese. Punta in modo ristretto solo dove i dati cambiano.
- **Rendering.** Un browser headless costa molto più CPU, memoria e traffico per pagina rispetto a un client HTTP. Renderizza solo le pagine che necessitano JavaScript.
- **DNS.** Con `socks5h://` o la porta HTTP, il DNS si risolve all'uscita; non serve una cache locale per gli host target.

## Domande sulla concorrenza

### CrawlRelay limita il numero di thread o di connessioni?

I piani sono fatturati per GB di traffico, non per thread, connessione o richiesta, e i piani pubblicati non impongono conteggi di thread. I limiti pratici sono la tolleranza di ogni target e la capacità della tua macchina. Se pianifichi una crawl molto ampia, scrivi prima a support@crawlrelay.com così possiamo verificare la copertura del tuo targeting.

### Perché la mia crawl è diventata più lenta aumentando i thread?

Di solito perché il target ha iniziato a throttling: aumentano i tempi di risposta, compaiono risposte 429 o 503, e i retry aggiungono carico. L'altra causa comune è esaurimento di CPU o socket sulla tua macchina, specie con browser headless. Misura latenza ed errori per host prima di aumentare i thread.

### È più lento fare una connessione per richiesta rispetto a keep-alive?

Sì, di uno handshake TCP e TLS per richiesta, tipicamente qualche centinaio di millisecondi tramite uscita residenziale. Questo è il prezzo per un nuovo IP a ogni richiesta. Per molte pagine dello stesso sito dove l'IP non conta, una sessione sticky con keep-alive è più veloce e usa meno traffico.

### Come rispetto il crawl-delay di robots.txt in un crawler concorrente?

Analizza robots.txt una volta per host, memorizzalo in cache fino a 24 ore come suggerito da RFC 9309, e trasforma un valore `Crawl-delay` in un intervallo minimo per host tra richieste con concorrenza 1. Il Python `urllib.robotparser` lo espone tramite `crawl_delay()`.

**Scala con prezzi per GB** 0,50 USD/GB da 50 GB a 1 TB, traffico che non scade mai. [Vedi i prezzi](https://crawlrelay.com/it/pricing/) · [Calcolatore di banda](https://crawlrelay.com/it/guides/bandwidth-calculator/)

---

CrawlRelay: CrawlRelay è un servizio di proxy residenziali rotanti e proxy mobili 4G/5G primo per sviluppatori: traffico pay-as-you-go senza scadenza da 0,50 USD/GB, pagato in crypto, senza caricamento documenti. Senza KYC — niente documento, selfie o altri documenti. Paga in crypto.