Исправление wolverin, (текущая версия) :
вопщим в потоке-методе добавляющем задачи в приоритетную очередь сделал в той же критической секции что и добавление еще проверку выполняется ли основная обработка и какой приоритет текущей обработки в сравнении прилетевшим + за критической секцией этого метода по результатам проверки добавил создание через лямбду деатач-потока с новым подключением к базе, выгребающего все приоритеты из очередь до прилетевшего уровня с обновлением текущего обрабатываемого приоритета.
статистика в проде показала, что низкоприоритетная задача может выполняться от 10 до 60 секунд (avg 30 сек) при этом грузят одно из 2х ядер моего «селерона» на 100%, нагрузочной статистики высокоприоритетных задач у меня нет окромя простой синтетической, не позволяющей создать волну нагрузки, но в целом вроде решение работает в той идеи, что не требуется создавать кучу потоков с кучей подключений к базе по произвольному количеству приоритетов.
зы. да согласен что пулл был бы быстрее, но и в таком варианте пока отклил очень хороший, при этом не гружу на 100% всю систему, не удерживаю кучу ресурсов когда это не нужно, а это имхо и есть эффективность.
Исправление wolverin, :
вопщим в потоке-методе добавляющем задачи в приоритетную очередь сделал в той же критической секции что и добавление еще проверку выполняется ли основная обработка и какой приоритет текущей обработки в сравнении прилетевшим + за критической секцией этого метода по результатам проверки добавил создание через лямбду деатач-потока с новым подключением к базе, выгребающего все приоритеты из очередь до прилетевшего уровня с обновлением текущего обрабатываемого приоритета.
статистика в проде показала, что низкоприоритетная задача может выполняться от 10 до 60 секунд (avg 30 сек) при этом грузят одно из 2х ядер моего «селерона» на 100%, нагрузочной статистики высокоприоритетных задач у меня нет окромя простой синтетической, не позволяющей создать волну нагрузки, но в целом вроде решение работает в той идеи, что не требуется создавать кучу потоков с кучей подключений к базе по произвольному количеству приоритетов.
зы. да согласен что пулл был бы быстрее, но и в таком варианте пока отклил очень хороший, при этом не гружу на 100% всю систему, а это имхо и есть эффективность.
Исправление wolverin, :
вопщим в потоке-методе добавляющем задачи в приоритетную очередь сделал в той же критической секции что и добавление еще проверку выполняется ли основная обработка и какой приоритет текущей обработки в сравнении прилетевшим + за критической секцией этого метода по результатам проверки добавил создание через лямбду деатач-потока с новым подключением к базе, выгребающего все приоритеты из очередь до прилетевшего уровня
статистика в проде показала, что низкоприоритетная задача может выполняться от 10 до 60 секунд (avg 30 сек) при этом грузят одно из 2х ядер моего «селерона» на 100%, нагрузочной статистики высокоприоритетных задач у меня нет окромя простой синтетической, не позволяющей создать волну нагрузки, но в целом вроде решение работает в той идеи, что не требуется создавать кучу потоков с кучей подключений к базе по произвольному количеству приоритетов.
зы. да согласен что пулл был бы быстрее, но и в таком варианте пока отклил очень хороший, при этом не гружу на 100% всю систему, а это имхо и есть эффективность.
Исходная версия wolverin, :
вопщим в потоке-методе добавляющем задачи в приоритетную очередь сделал в той же критической секции, что и добавление еще проверку выполняется ли основная обработка и какой приоритет текущей обработки в сравнении прилетевшим + за критической секцией этого метода по результатам проверки добавил создание через лямбду деатач-потока с новым подключением к базе, выгребающего все приоритеты из очередь до прилетевшего уровня
статистика в проде показала, что низкоприоритетная задача может выполняться от 10 до 60 секунд (avg 30 сек) при этом грузят одно из 2х ядер моего «селерона» на 100%, нагрузочной статистики высокоприоритетных задач у меня нет окромя простой синтетической, не позволяющей создать волну нагрузки, но в целом вроде решение работает в той идеи, что не требуется создавать кучу потоков с кучей подключений к базе по произвольному количеству приоритетов.