Парсинг Ozon: сколько адресов уходит на полный каталог

До вчерашнего дня всё шло ровно, потом началось.

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

Хочу понять устройство, а потом уже крутить настройки.

Был случай, когда всё сошлось только на третий день разбора.

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

Тема на будущее пригодится многим.

Был случай, когда всё сошлось только на третий день разбора.

Если программа ест память, дело почти всегда в накоплении результата. Настройте запись на диск пачками, и потолок исчезнет.

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

Это на всех площадках или на одной?

Верно по сути, дальше нюансы.

Если программа ест память, дело почти всегда в накоплении результата. Настройте запись на диск пачками, и потолок исчезнет.

Расскажу, как выкручивались мы.

Если программа ест память, дело почти всегда в накоплении результата. Настройте запись на диск пачками, и потолок исчезнет.

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

Полезный разбор получился.

Ставьте паузу с разбросом, не ровную.

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

Сборщик, который умеет продолжить с места обрыва, стоит вдвое дороже по времени разработки и вдесятеро дешевле в работе.

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

Тот же вывод, только я шёл к нему дольше.

Бесконечная прокрутка обычно означает отдельный запрос за каждой порцией. Найдите его, и сбор становится обычным.

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