На данный момент распределение активных потоков в задачах идет последовательно по времени задачи. То есть - освободившиеся потоки перебрасываются на задачу созданную по времени раньше остальных. Предложение - добавить параметр для приоритетности по распределению потоков по анологии с распределением слотов.
какая практическая ценность? по мне никакой, из минусов - усложняет логику, замедлит работу парсера в целом
Практическая ценность - есть задачи, которые хотелось бы выполнить в первую очередь, не смотря на то что они были добавлены позже других. Есть задачи не требующие быстрого ответа, есть задачи ответ которых должен быть получен как можно быстрее.
В нашем случае данный функционал нужен для того, чтобы решить следующие задачи - важные (срочные) задачи не должны ждать выполнения всего стека, длина обработки которого может доходить до нескольких часов - короткие задачи нужно "просовывать" вперед - разные пользователи должны иметь разный приоритет (в зависимости от подписок и т.п.) - очень длинные задачи (от часа до дней) должны не мешать остальным задачам, работая только с невостребованными потоками
Полностью поддерживаю автора топика по необходимости данного улучшения, т.к. получается такая ситуация, что никак не удается закончить очень большое низкоприоритетное задание, из за того, что приходится выполнять много высокоприоритетных но коротких заданий. А когда они заканчиваются апарсер простаивает, вместо того, чтобы выполнять низкоприоритетное задание.
Потому как низкоприоритетное задание было остановлено. Когда высокоприоритетные закончили парсинг, нужно снова включить низкоприоритетное. А когда через апи придет высокоприоритетное, ставить низкоприоритетное на паузу и запускать сразу по завершению. Хотелось бы это автоматизировать чтобы оно само выключалось и включалось , если других заданий нет в очереди.
Почему нельзя поставить несколько копий парсера на сервер для разной группы приоритетов, поставить перед ним балансировщик, который в зависимости от типа ( группа задач) роутит на нужный парсер? Можно использовать haproxy в качестве балансировщика. Единственно, что задачи с низким приоритетом не будут ставится на паузу, а будут работать, как работали, нагружая сервер или используя нужные потоки для прокси, которые могут быть ограничены, etc.
не хотелось бы пользоваться костылями и потоки прокси ограничены... надеюсь в ближайших обновлениях добавят это.
Это не совсем костыли, в том числе для того load balancing (а так же middlewares и тому подобное) и были придуманы.Я привел пример решения, которое можно сделать прямо сейчас, а ждать нового функционала можно бесконечно долго. На подобной архитектуре держится много софта, это отработанное решение годами.
Добавлена возможность указать приоритет заданию: Задания с большим приоритетом будут получать потоки сразу после завершения каждого запроса у заданий с меньшим приоритетом Если у заданий приоритет одинаковый то преимущество отдается заданию которое было раньше добавлено по времени Работает только с динамическим лимитом потоков При добавлении задания через API необходимо указывать поле prio от 1 до 100(больше - выше)
Апдейт может вызвать проблемы! Поставил 839, парсеры не поднялись, логи не пишут. Откатил на 838 - всё опять заработало. В деталях пока не разбирался.
