再一次，Rufus-Scheduler很棒!!

Question

我在这里建立一个类似IFTTT的平台。

简而言之，rufus调度程序很棒。我知道它使用线程池（默认情况下为28个线程？=＆gt; 3.x.x）

我的平台预计可以处理超过1000个时间表。

在Jruby上，作为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核1GB RHEL 64位Vmware和4核4GB RHEL 64位Vmware上运行此代码。

Jruby版

labtop jruby 1.7.16.1（1.9.3p392）
Linux jruby 1.7.19（1.9.3p551）

这些不完全相同，但它应该没问题。？链接图是所有间隔的平均值。 Benchmark Result

我可以保持增加最大线程以找出性能峰值。但我决定不这样做。我会在生产环境中使用更好的机器。延迟1000~2000ms应该不成问题。（基准最大延迟为1核心时700毫秒）

再一次，Rufus-Scheduler很棒!!

Answer 2

Rufus-scheduler按顺序排列其日程表＆＃34;旁边首先触发＆＃34;。所以你的列表可能会变长，但是rufus每次都不会循环遍历整个列表（并且每次都意味着每隔约0.3s（默认频率）），一旦下一个元素是＆＃34;它就会停止迭代。在未来＆＃34;。所以一长串清单应该没问题。

阅读问题，我的印象是你更关心大量的时间表同时触发和/或重叠。 IIRC，JRuby使用Java线程，据说它们是多核友好的，所以好的硬件可以提供帮助。

为什么不建造原型？你用计划轰炸它并观察，学习，调整（如果不够好，可能会丢弃rufus-scheduler）。建立你的基准，然后回答你的问题。

rufus调度程序可以处理多少个调度？

2 个答案:

再一次，Rufus-Scheduler很棒!!