Улучшение Проксёвые настройки из потока в Прокси чекер

[egorka]

Сегодня запутался в том, что у потока своя настройка прокси чекера, у парсеров свои отдельные настройки. Логика "наследования" настроек не вполне очевидна. Что "All" в настройках парсера следует читать как "inherit" от потока.

Например, настройка "Reuse proxy between retries" относится скорее к конкретному парсеру, его "личному" прокси-чекеру, нежели к потоку, всему заданию... Ведь поведение конкретного чекера (интервалы, баны) зависит именно от парсера.

А настройки всего задания (потока) - это по сути просто число потоков. И всё! Все проксёвые настройки должны относится к прокси-чекерам. Тогда логика будет соблюдена без сложностей с наследованием.

В общем, каждому парсеру по своему прокси чекеру. Без наследования и замороки!

 

[stive84]

ОЧЕНЬ поддерживаю. Bulk/one request катастрофически плохо работают с StromProxy, например, именно из-за отсутствия возможности указать в настройках "Reuse proxy between retries". Для понимания ситуации - сервис выдаёт 4 IP, за которыми ротируются десятки тысяч проксей, и без Reuse - парсинг моментально встаёт колом. С саппортом постарались решить проблему (как всегда очень большая благодарность саппорту за терпение и поддержку), указав Proxy ban time в настройках пресета парсера на 0, но это по тестам никакого толкового результата не даёт, работает как задумано именно Reuse proxy, а его при работе через bulk использовать невозможно.

 

[Forbidden]

Подумать о переносе Reuse proxy between retries в настройки парсера или проксичекера

 

[stive84]

Есть какие-нибудь новости по subj? А то топчемся на месте, уже разработали всё что можно по кругу минуя задачи парсинга, очень хотелось бы приступить
Ну и небольшим доп. стимулом будет необходимость после реализации subj в покупке ещё одной лицензии Enterprise

 

[Forbidden]

Реализована возможность задать configPreset в API запросах oneRequest/bulkRequest

Переносить найстроку в проксичекеры или раздувать настройки парсеров нецелесообразно