Парсинг маркетплейсов: карточки меняют разметку раз в месяц

Пишу подробно, потому что вопрос всплывает у всех, кто работает с объёмами.

Кратко по условиям.

Список на 120 тысяч адресов, окно на прогон шесть часов. Скорость держится первые два часа, потом падает.

$ ./sbor --potokov 120 --spisok chast-01.txt --proksi pool.txt
обработано: 48 210 / 50 000
пустых ответов: 1 842

Что тут вообще считается нормой?

Могу подтвердить, у нас на двух проектах точно так.

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

Разметка на маркетплейсах меняется регулярно. Держите разбор в одном месте, чтобы правка занимала минуту вместо полдня.

$ ./sbor --potokov 120 --spisok chast-01.txt --proksi pool.txt
обработано: 48 210 / 50 000
пустых ответов: 1 842

Сколько это длится и с какой частотой повторяется?

Настройка применилась вообще?

Начинал с готовых сервисов, потом ушёл на своё.

Разметка на маркетплейсах меняется регулярно. Держите разбор в одном месте, чтобы правка занимала минуту вместо полдня.

Перед сменой поставщика адресов сделайте контрольный прогон на одинаковой задаче. Иначе разницу в скорости будете объяснять чем угодно, кроме настоящей причины.

Всё верно написали выше, добавлю от себя пару деталей.

Перед большим прогоном всегда гоняю пробу на тысяче адресов. Три минуты времени, и сразу видно, где посыплется.

Полгода назад ловил то же самое.

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

$ ./sbor --potokov 120 --spisok chast-01.txt --proksi pool.txt
обработано: 48 210 / 50 000
пустых ответов: 1 842

Пусть висит, такие вопросы всплывают постоянно.

Пробовали снизить темп вдвое?

Сначала делал так же, потом переделал всё.

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