Сколько графиков можно обработать планировщиком rufus?

Question

Я строию платформу IFTTT.

Короче говоря, планировщик rufus замечательный. и я знаю, что он использует пул потоков (по 28 потоков по умолчанию? => 3.x.x)

Планируется, что на моей платформе будет работать более 1000 расписаний, а может быть и больше.

на Jruby, as Singleton. Есть ли проблема с этим ожиданием? я должен увеличить максимальный размер пула потоков? то сколько потоков я должен увеличить? Есть ли руководство по этой проблеме?

Answer 1

Я закончил бенчмарк, код выглядит следующим образом. Моя система имеет очередь заданий, поэтому обработчик rufus-scheduler будет выполнять только короткие и легкие задачи. Например, задания в очереди. В коде, только интервал регистрации между job.last_time и раз. Я предполагал, что чем больше интервал, тем ниже производительность. как «задержка»

require 'rufus-scheduler' 
require 'awesome_print' 
require 'logger' 

SCHEDULE_COUNT = 1000 
MAX_THREAD = 224 
schedule_samples = { type: "cron", schedule: "* * * * *"} 

$logger = Logger.new("benchmark.log") 
scheduler = Rufus::Scheduler.singleton(:max_work_threads => MAX_THREAD) 

class Handler 
    def self.call(job, time) 
    $logger.info job.last_time - time 
    end 
end 

SCHEDULE_COUNT.times do 
    scheduler.send(schedule_samples[:type].to_sym, schedule_samples[:schedule], Handler) 
end 

sleep 600 

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

Я запустил этот код на своем ноутбуке, 1-ядерный 1-гигабайтный RHEL 64-битный Vmware и 4-ядерный 4-гигабайтный RHEL 64-бит Vmware.

JRuby версия

• Labtop JRuby 1.7.16.1 (1.9.3p392)
• Linux JRuby 1.7.19 (1.9.3p551)

Это не совсем то же самое, но она должна быть в порядке..? Диаграмма ссылок - среднее значение всех интервалов. Benchmark Result

---

Я могу держать увеличение максимум нити, чтобы выяснить, пик производительности. Но я решила, что не сделаю этого. Я буду использовать лучшую машину для производственной среды. Задержка 1000 ~ 2000 мс не должна быть проблемой. (в тесте наибольшая задержка составляла 700 мс на 1 ядре)

Опять же, Rufus-Scheduler отлично!

Answer 2

Rufus-scheduler ставит в очередь свои расписания в порядке «рядом с первым запуском». Таким образом, ваш список может занять много времени, но rufus не перебирает весь список каждый раз (и каждый раз означает каждые 0,3 с (частота по умолчанию)), он прекращает итерацию, как только следующий элемент «в будущем». Поэтому длинный список должен быть в порядке.

Чтение вопроса. У меня создается впечатление, что вы больше беспокоитесь о запуске сразу нескольких расписаний и/или перекрытии. IIRC, JRuby использует потоки Java, и считается, что они являются многоядерными, поэтому хорошее оборудование может помочь.

Почему вы не строите прототип? Вы бомбите его расписаниями и наблюдаете, учитесь, настраиваете (и, возможно, отбрасываете rufus-scheduler, если не достаточно). Постройте свой тест, затем ответы на ваш вопрос придут к вам.