ruby-on-rails – Delayed_job与Appoxy SimpleWorker

前端之家收集整理的这篇文章主要介绍了ruby-on-rails – Delayed_job与Appoxy SimpleWorker前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
当我在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!

解决方法

嗨(这是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请求(?)(尽管现在可能已经改变了,所以我鼓励你自己检查一下,以确定,也许它不是一个大的对你来说是一个问题,因为它对我而言).对我来说,每次我想添加新的工作类并且不得不从我的应用程序和我的宝石中加载所有单独的代码片段到工作类文件本身时,只是太麻烦/反复试验,而运行heroku ps :工作者1或heroku ps:scale worker = 2会立即启动一个或两个工作人员并开始处理,对我的代码库进行零修改,与我在本地运行时完全相同,因为我的整个应用程序已经编译为slug在Heroku上它只使用它,包括我的ENV变量和其他设置/插件,它快速旋转.

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

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

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

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

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

希望这可以帮助!

猜你在找的Ruby相关文章