Многопоточность в BAS: сколько потоков ставить и почему больше - не быстрее

Многопоточность - то, ради чего BAS вообще берут: один и тот же скрипт крутится в несколько параллельных копий, и работа, которая заняла бы сутки, укладывается в час. Но число потоков - не ползунок «сделать быстрее». Это распределение конечного ресурса, и после определённой цифры бот начинает работать медленнее.

Что такое поток в BAS

Поток - это независимая копия вашего скрипта, выполняющаяся параллельно с остальными. Ключевое слово - независимая: у каждого потока свой браузер, свои профиль и отпечаток, свой набор cookies, свой прокси и свои значения переменных.

Именно поэтому многопоточность в BAS даёт не просто скорость, а параллельную работу с разными аккаунтами: поток №3 ничего не знает о том, под кем залогинен поток №7.

Чего у потока нет

Изоляция не абсолютна. Общими остаются:

• Файлы на диске - если два потока пишут в один файл, они будут мешать друг другу.
• Ресурсы - это общая очередь, и правило раздачи вы задаёте сами.
• База данных - встроенное хранилище одно на все потоки.
• Внешние лимиты - квота API или лимит на IP не удваиваются оттого, что вы удвоили потоки.

Отсюда главное правило: всё, что у потоков общее, должно быть либо только на чтение, либо защищено от гонки. Запись логов в один файл из двадцати потоков - классический способ получить перемешанные строки.

Как считать потолок

Считайте по памяти, а не по ощущениям. Один браузерный поток в BAS занимает примерно 150-400 МБ RAM - разброс зависит от тяжести сайта: лёгкая форма ближе к нижней границе, сайт с видео и картинками уверенно уходит к верхней.

Формула простая:

потоки = (свободная RAM - 2 ГБ запаса) / 400 МБ

На VPS с 8 ГБ это примерно 10-15 браузерных потоков. Если браузер не нужен и вы работаете HTTP-клиентом, картина другая: там расход на поток измеряется мегабайтами, и сотня потоков - норма.

Процессор - второе ограничение. Рендеринг страниц упирается в CPU, и на слабом ядре вы поймаете потолок по процессору раньше, чем по памяти.

Как понять, что потоков слишком много

Симптомы узнаваемые:

• Растут таймауты - действия начинают падать по ожиданию, хотя раньше проходили.
• Падает доля успешных итераций в статистике, а общая скорость не растёт.
• Резко чаще выпадает капча - сайт видит одинаковый нездоровый ритм с одного IP.
• Машина уходит в подкачку, и тормозят все потоки разом.

Последний пункт коварен тем, что деградация не постепенная, а обвальная: до порога всё хорошо, за порогом плохо сразу везде.

Как искать рабочее число

Не угадывайте - измеряйте. Рабочий метод:

1. Запустите на одном потоке и замерьте время одной полной итерации.
2. Поднимите до 5, снова замерьте - итерация должна остаться примерно такой же по времени.
3. Продолжайте удваивать, пока время одной итерации не начнёт расти.
4. Откатитесь на шаг назад и снимите ещё 20% - это ваш рабочий режим.

Смысл в том, что вас интересует не число потоков, а суммарная пропускная способность. Двадцать потоков, где каждая итерация втрое дольше, работают хуже восьми здоровых.

Раздача ресурсов и прокси

При многопоточной работе способ подачи данных важнее самого числа потоков. Если каждый поток берёт строку из общего списка - убедитесь, что строка не достаётся двоим сразу, иначе вы дважды обработаете один аккаунт и оба раза криво.

То же с прокси: один IP на двадцать потоков сводит на нет всю изоляцию профилей - сайт увидит двадцать «разных» браузеров с одного адреса. Многопоточность имеет смысл только тогда, когда за потоками стоят разные адреса.

Когда потоки не помогут

Многопоточность ускоряет то, что ограничено ожиданием: загрузка страниц, сетевые задержки, паузы. Она не ускоряет то, что ограничено внешней стороной - если сайт пускает 10 запросов в минуту, тридцать потоков просто получат бан быстрее, чем десять.

Прежде чем повышать потоки, посмотрите, где на самом деле уходит время. Часто выгоднее убрать лишнее ожидание внутри итерации, чем множить копии скрипта: сокращение итерации на 30% даёт тот же эффект, что и треть новых потоков, но бесплатно по ресурсам.