6

当我在 Heroku 上找到 Appoxy SimpleWorker 时，我正要开始在我的应用程序上启动并运行延迟作业。

Appoxy 说它是大规模并行的，它可以上下扩展工作人员以最大限度地降低成本。但是，在我看来，使用 HireFire，delayed_job 也是如此。这是我的问题：您会选择哪一个：delayed_job + HireFire 或 SimpleWorker？（为什么？）

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

我的应用程序目前很小 - 音量很低，应用程序的数量在很长一段时间内不应该特别多。

还有什么地方可以期望直接从这两种服务的创始人那里得到答复？谢谢迈克尔和特拉维斯！

4

3 回答 3

5

嗨（这是 HireFire 的作者）

我将尝试提供一些有关服务之间差异的信息。不确定它是否对您的决定有很大帮助，但至少它是一些东西！

两种解决方案都采用不同的方法。HireFire 仅在必要时扩展您的 Heroku 网络和工作人员测功机。您无需更改现有代码库中的任何内容，只需照常使用延迟作业。您不必为单独的环境/平台发送/编写代码，因为它在部署时在 Heroku 平台上编译为 slug，并且当新的 web 或 worker dyno 启动时，slug 会立即使用并运行（包含您的所有ENV 变量/设置。

与 SimpleWorker 相比，HireFire 的缺点是 HireFire 是 Heroku 特有的。因此，如果您曾经从 Heroku 切换到例如 EngineYard 或 VPS/Dedicated 盒子，那么 HireFire 将无法工作，但 SimpleWorker 会因为它没有严格绑定到 Heroku。虽然，在非 PaaS 平台上托管可能非常便宜（相比之下），因此不一定需要或根本不需要自动缩放。

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

使用 HireFire，您只需将hidefireapp gem添加到您的 Gemfile，将您的 Heroku 帐户/应用程序添加到 HireFire Web 界面，自定义您的扩展需求，将您的应用程序部署到 Heroku，仅此而已。您的应用程序将被持续监控和管理/调整（按分钟或更短时间）。

HireFire 没有带有工作表及其状态（运行/完成/失败/等）的光滑界面（当然，它确实概述了每个应用程序的当前 web/worker dyno 数量和排队工作，并且可定制的缩放设置），尽管这确实是工作库提供此类功能的工作。据我所知，Delayed Job 有一个或两个你可以使用的小管理界面（开源），它们与 HireFire 无关。因为 SimpleWorker 它既是一个托管服务，又是一个工作库，它们也为您提供了一个 Web 界面。

HireFire 还能够扩展您的网络测功机，而不仅仅是您的工作人员测功机。

两种服务都能够并行处理大量工作，因为据我所知，Heroku 和 SimpleWorker 都按比例分配到第二个。因此，无论您旋转 10 个工人测功机 6 秒，还是 1 个 60 秒，都不会（或几乎没有）成本。

我自己发布了 HireFire 之后就没有使用过 SimpleWorker，那是很久以前的事了，所以我不确定 SimpleWorker 这些天还提供了什么，或者他们是否从那时起简化了流程，所以我不确定我上面的陈述是否此时仍然有效。

希望这可以帮助！

于 2011-09-13T07:44:41.940 回答
4

嗨（SimpleWorker 的创始人），

Michael 总结得很好，但我将添加一些 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 有任何疑问，请随时问我。

于 2011-09-13T21:54:39.943 回答
0

我使用延迟工作，然后根据我的数据库中是否有任何延迟工作来使用 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 的成本，并且基本上只为我使用的东西付费。

于 2012-04-04T18:46:29.140 回答