Sesiones concurrentes (hilos)
El número de conexiones o solicitudes simultáneas que puedes ejecutar a través de un servicio de proxy al mismo tiempo.
Las sesiones concurrentes -a menudo llamadas hilos- son el número de conexiones simultáneas que puedes tener abiertas a través de un servicio de proxy a la vez. Si tu plan permite 100 sesiones concurrentes, puedes ejecutar 100 solicitudes en paralelo; la 101ª espera hasta que una termine. La concurrencia es una palanca principal sobre la rapidez con la que puedes hacer scraping.
Determina directamente el rendimiento. La velocidad total es aproximadamente la concurrencia multiplicada por la velocidad por solicitud. Duplicar las sesiones concurrentes duplica aproximadamente cuántas páginas puedes obtener por minuto, hasta el punto en que los propios límites del destino o tu pipeline de parsing se convierten en el cuello de botella. El scraping de alto volumen necesita alta concurrencia.
Los proveedores tarifican y empaquetan la concurrencia de forma distinta. Algunos planes basados en tráfico permiten sesiones concurrentes prácticamente ilimitadas y cobran solo por los datos transferidos; otros limitan la concurrencia por nivel de plan. Saber si tu límite es la concurrencia, el ancho de banda o ambos es esencial para dimensionar una operación de scraping.
Más concurrencia no siempre es mejor. Demasiadas solicitudes en paralelo contra un solo destino -incluso a través de IPs rotativas- puede activar defensas a nivel de todo el sitio o saturar el destino. Equilibra la concurrencia con los límites por IP y un ritmo prudente para escalar el rendimiento sin llamar la atención.
Counting what runs at the same time
Concurrency is how many requests are in flight simultaneously, and it is the number that decides throughput. A job of a million pages at one request at a time takes weeks. The same job at two hundred at a time takes hours. Nothing else about the job changed.
Two different limits apply, and confusing them wastes money. The provider limit is how many connections the proxy service will accept from you. The target limit is how many the destination tolerates from a single address before it starts refusing, usually as 429 or a silent slowdown.
The target limit is per address, which is the important part. Doubling concurrency through one address doubles your rate against that address and gets you rate-limited twice as fast. Doubling the number of addresses while keeping per-address concurrency the same doubles throughput without changing what any single address looks like.
There is also a cost dimension on metered products. Concurrency does not change how many bytes you transfer, so it costs nothing extra on residential. It changes only how quickly you spend the same money.
Our limits, and the ones that will actually stop you
We do not cap concurrent connections or session count on residential. The ceiling you meet in practice belongs to the destination:
Scaling by addresses, not by threads
# Wrong: 200 threads through one session
login_c_US_s_1_ttl_15m x200 threads -> 429 from the target
# Right: 200 threads across 50 sessions
login_c_US_s_1_ttl_15m x4 threads
login_c_US_s_2_ttl_15m x4 threads
...
login_c_US_s_50_ttl_15m x4 threads
# Or drop sessions entirely for a new exit per request:
login_c_US- Rotating residential without a session id spreads requests across exits automatically, which is the simplest way to raise concurrency safely.
- On static addresses, concurrency per address is what you tune. Twenty datacenter addresses at ten threads each behaves very differently from one address at two hundred.
- Reuse connections. A pooled client keeps the tunnel to us open and removes a handshake from every request, which often matters more than raising thread counts.
- Watch for 429 rather than guessing. It is the target telling you exactly which limit you crossed.
Where concurrency planning goes wrong
Treating provider limits as the constraint
We do not cap concurrency. If you are being throttled, the destination is doing it, and more threads will make it worse.
Confusing sessions with connections
One sticky session can carry many parallel connections through the same exit. That is usually not what you want under load.
Raising threads to fix slowness
If responses are slow because the target is throttling you, more parallelism increases the queue rather than the throughput.
Assuming concurrency costs more on residential
Billing follows bytes, not connections. Concurrency changes how fast you spend, not how much.
Términos relacionados
Ver esto en práctica
¿Listo para usar sesiones concurrentes (hilos)?
SotaProxy te da acceso a proxies residenciales rotativos, móviles, de centro de datos e ISP. Sin compromiso mínimo.
Empezar