Сборщик на потоках отваливается через 20 минут работы

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

Вводные, чтобы не гадать.

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

$ ./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

Это началось после какого-то изменения?

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

Тут легко перепутать два разных момента.

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

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

Меняйте по одному, иначе не поймёте причину.

Считайте на адрес. Общая цифра по прогону вводит в заблуждение.

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

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

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

Согласен с предыдущим ответом, но с одной оговоркой.

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

Тут не всё так однозначно, смотря какой объём.

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

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

Ловил это дважды, оба раза по разным причинам.

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

Логи в помощь, без них это гадание.