Delayed_job与Appoxy SimpleWorker

时间:2011-09-12 07:50:25

标签: ruby-on-rails ruby-on-rails-3 heroku delayed-job hirefire

当我在Heroku上找到Appoxy SimpleWorker时,我正准备启动delayed_job并在我的应用程序上运行。

Appoxy表示它大规模并行,并且可以上下调整工作人员以最大限度地降低成本。但是,在我看来,使用HireFire,delayed_job也是如此。这是我的问题:你会选择哪个:delayed_job + HireFire或SimpleWorker?(以及为什么?)

https://github.com/tobi/delayed_job
http://hirefireapp.com/
http://addons.heroku.com/simple_worker

我的应用程序目前很小 - 音量很低,应用程序的数量不应该非常高。


还有什么人可以期望直接从这两项服务的创始人那里得到回复?谢谢Michael和Travis!

3 个答案:

答案 0 :(得分:5)

嗨(这是HireFire的作者)

我将尝试提供有关服务之间差异的一些信息。不确定它对你的决定是否有多大帮助,但至少它是什么!

两种解决方案都采用不同的方法。 HireFire只是在必要时扩展您的Heroku网络和工作人员dynos。您不必更改现有代码库中的任何内容,只需正常使用延迟作业即可。您不必为单独的环境/平台发送/编写代码,因为它在部署时被编译为Heroku平台上的slug,当新的web或worker dyno旋转时,slug被使用并立即运行(包含所有你的ENV变量/设置。

与SimpleWorker相比,HireFire的缺点是HireFire是Heroku特有的。因此,如果您从Heroku切换到例如EngineYard或VPS / Dedicated框,那么HireFire将无法工作,但SimpleWorker将因为它与Heroku没有严格的关联。虽然,在非PaaS平台上托管可能非常便宜(相比之下),因此不一定需要自动扩展或根本不需要。

在开发HireFire之前,我一直是SimpleWorker的客户,而我个人不喜欢的是我必须将部分代码库推送到SimpleWorker,并在我的Rails环境中加载,从他们的数据库重新连接到数据库每次我想将作业发送到云时,服务器位置也会执行API请求(?)(虽然现在可能已经改变了,所以我鼓励你自己检查一下以确定,也许它不是对你而言,这对我来说是一个很大的问题)。对我来说,每次我想添加新的工作类并且不得不从我的应用程序和我的宝石中加载所有单独的代码片段到工作类文件本身时,只是太麻烦/反复试验,而运行{{ 1}}或heroku ps:workers 1会立即启动一个或两个工作人员并开始处理我的代码库零修改,与我在本地运行时完全相同,因为我的整个应用程序已经编译为Heroku上的一个slug它只是使用它,包括我的ENV变量和其他设置/插件,它会快速旋转。

使用HireFire,您只需将the hirefireapp gem添加到您的Gemfile,将您的Heroku帐户/应用程序添加到HireFire Web界面,自定义您的扩展需求,将您的应用程序部署到Heroku,就是这样。您的应用程序将持续受到监控和管理/调整(按分钟或更短时间)。

HireFire没有带有作业表及其状态(运行/完成/失败/等)的光滑界面(它确实概述了当前每个应用程序的web / worker dynos和排队作业数量当然,以及可自定义的缩放设置),尽管这确实是工作者库提供此类功能的工作。我所知道的延迟工作有一两个你可以使用的小管理界面(开源),它们与HireFire无关。因为SimpleWorker既是托管服务,也是一个工作库,它们也为您提供了一个Web界面。

HireFire也能够扩展您的网络动态,而不仅仅是您的工作人员。

两种服务都能够并行处理大量作业,因为Heroku和SimpleWorker都是按照我的理解按比例排名第二。因此,无论你将10个工作人员的dynos旋转6秒,还是1个60秒,都不会产生任何差异(或几乎没有)。

我自己在发布HireFire之后没有使用过SimpleWorker,这是很久以前所以我不确定SimpleWorker现在提供了什么,或者从那时起他们是否简化了这个过程,所以我不确定是否以上我所做的陈述目前仍然有效。

希望这有帮助!

答案 1 :(得分:4)

嗨(SimpleWorker的创始人),

迈克尔很好地总结了这一点,但我会在Heroku Workers和SimpleWorker之间添加一些差异,不一定是HireFire。

  • Heroku一次最多有24名工人,这意味着一次只能运行24个工作。使用SimpleWorker,您可以一次运行1000个(并且随着我们的增长而增加),而无需任何更改。
  • 使用SimpleWorker进行扩展不需要付出任何努力,因此随着应用程序的增长,您无需进行任何更改,只需继续按照自己的方式投入更多工作。
  • Heroku会收取您是否使用工作人员的费用,而SimpleWorker则不会。这是HireFire解决的问题,所以如果你使用的是HireFire,这不是问题。
  • SimpleWorker内置日程安排,因此您不需要cron或其他任何东西来启动您的工作。
  • 管理界面,以便您可以查看所有工作人员/工作,查找错误,获取错误警报,查看所有工作的日志等。

缺点是需要更多考虑使用SimpleWorker,因为它没有运行完整的Rails环境。您必须将您的工作者视为在不同系统上运行的独立实体(它们是)。对于简单的事情,例如在后台发送电子邮件或从您的前端卸载一些东西,Heroku Workers可能是一个不错的选择。如果您执行任何大型批处理作业,计划,长时间运行的作业,希望更多地了解您的作业等,那么您可能需要尝试使用SimpleWorker。

顺便说一句,我们最近发布了一些新视频,以便您了解它的工作原理和使用方式:http://www.simpleworker.com/how_it_works/videos

希望有所帮助!如果您有任何关于SimpleWorker的问题,请随时问我。

答案 2 :(得分:0)

我使用延迟工作,然后根据我的数据库中是否有任何delayed_jobs,使用rake任务来扩展我的heroku工作者:

namespace :heroku do
  namespace :workers do
    desc "stop heroku workers"
    task :stop do
      p ['stopping workers for', CONFIG['heroku_project']]
      Heroku::Client.new(ENV['HEROKU_EMAIL'], ENV['HEROKU_PASSWORD']).set_workers(CONFIG['heroku_project'], 0)
    end

    desc "start heroku workers"
    task :start do
      p ['starting workers for', CONFIG['heroku_project']]
      Heroku::Client.new(ENV['HEROKU_EMAIL'], ENV['HEROKU_PASSWORD']).set_workers(CONFIG['heroku_project'], 1)
    end

    desc "starts workers if the are items in the queue, otherwise, stops them."
    task :check_queue => :environment do
      p ["Env: ", Rails.env]
      count = DelayedJob.find_pending.count
      p ['Pending delayed jobs: ', count]
      if count > 0
        Rake::Task['heroku:workers:start'].invoke
      else
        Rake::Task['heroku:workers:stop'].invoke
      end
    end
  end
end

使用调度程序附加组件,我可以每10分钟检查一次我的工作人员以降低成本。

我喜欢这个解决方案因为我可以使用DelayedJob(我很熟悉),而不是使用另一个插件或第三方所有我需要的是一个简单的rake任务来限制Heroku的成本而且基本上只支付我的费用使用