Реферальна програма →
ГоловнаГлосарійОдночасні сесії (потоки)
Глосарій

Одночасні сесії (потоки)

Число одночасних з’єднань або запитів, які ви можете вести через проксі-сервіс в один момент.

Одночасні сесії - часто звані потоками - це число одночасно відкритих з’єднань через проксі-сервіс. Якщо ваш тариф допускає 100 одночасних сесій, ви можете вести 100 запитів паралельно; 101-й чекає, поки один завершиться. Паралельність - головний важіль того, як швидко ви скрапите.

Вона напряму визначає пропускну здатність. Загальна швидкість приблизно дорівнює паралельності, помноженій на швидкість одного запиту. Подвоєння одночасних сесій приблизно подвоює число сторінок, які ви можете отримати за хвилину, - до точки, де вузьким місцем стають ліміти самої цілі або ваш парсинг-конвеєр. Високооб’ємному скрапінгу потрібна висока паралельність.

Провайдери по-різному тарифікують і пакують паралельність. Одні тарифи на основі трафіку допускають фактично необмежене число одночасних сесій і беруть плату лише за передані дані; інші обмежують паралельність рівнем тарифу. Знання того, чи обмежені ви паралельністю, трафіком чи обома, критичне для розрахунку розміру скрапінг-операції.

Більше паралельності не завжди краще. Занадто багато паралельних запитів до однієї цілі - навіть через ротовані IP - може ввімкнути захист рівня всього сайту або перевантажити ціль. Балансуйте паралельність із лімітами на IP і ввічливим темпом, щоб масштабувати пропускну здатність, не привертаючи уваги.

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.

Дивись на практиці

Готовий використовувати одночасні сесії (потоки)?

SotaProxy надає доступ до ротуючих резидентських, мобільних, дата-центр та ISP проксі. Без мінімальних платежів.

Почати