Delayed_job vs Appoxy SimpleWorker

Question

I was about to start getting delayed_job and work in my application when I found Appoxy SimpleWorker on Heroku.

Appoxy says that it is widely parallel and that it scales workers up and down to minimize costs. However, it seems to me that with HireFire is also delayed_job. Here is my question: which one would you choose: delayed_job + HireFire or SimpleWorker? (and why?)

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

My application is currently small - the volume is low, and the number of applications should not be unusually high for a good time.

---

Where else can you expect to receive answers directly from the Founders of both services? Thanks Michael and Travis!

Answer 1

Hi (this is the author of HireFire)

I will try to provide some information about the differences between the services. Not sure if this will help with your decision, but at least it is something!

Both solutions use a different approach. HireFire simply scales your Heroku website and dinosaurs when needed. You do not need to change anything in your existing codebase, you just use the Delayed Job as usual. You do not need to send / write code for a separate environment / platform, since it was compiled as a pool on the Heroku platform after deployment, and when a new web or working speaker is deployed, slug is used and launched immediately (containing all your ENV variables / settings.

The downside of HireFire compared to SimpleWorker is that HireFire is Heroku specific. Therefore, if you ever switch from Heroku to, for example, EngineYard or VPS / Dedicated, then HireFire will not work, but SimpleWorker will, because it is not strictly tied to Heroku. Although it is probably very cheap to host on a platform other than PaaS (in comparison), therefore, automatic scaling is not necessarily required as much or at all.

I was a SimpleWorker client before the development of HireFire, and I personally did not like the fact that I had to embed part of my code base into SimpleWorker and load it into the Rails environment, reconnect to the database from their servers, and also execute API requests (?) Every time when I want to send the task to the cloud (although this may change now, so I recommend that you make sure that it is mandatory, and maybe this is not a big problem for you, as for me). For me, it was just too much hassle / trial and error every time I wanted to add new work classes, and I had to load all the separate parts of the code from my application and my gems into the work class files themselves, whereas when running heroku ps:workers 1 or heroku ps:scale worker=2 instantly expands a worker or two, and starts processing with zero changes in my code base, just like when I run it locally, since my entire application has already been compiled as a bullet on Heroku it just uses it, including my re Variable ENV and other settings / add-ons, and it rotates quickly.

With HireFire, you just need to add the rentfireapp gem to your Gemfile, add your Heroku account / application to the HireFire web interface, configure your needs scaling, deploy your Heroku application, and what it is. Your applications will be constantly monitored and controlled / adjusted (for a minute or less).

HireFire does not have a smooth interface with job tables and their status (running / finished / failed / etc) (it has an overview of the current number of workstations / workstations and jobs in the queue for each application by the course and customizable scaling settings), although it really does work libraries to provide this functionality. The deferred task from what I know has one or two small admin interfaces that you could use (open source) that are not tied to HireFire. Since SimpleWorker is both a hosted service and a working library in one, they also provide you with a web interface.

HireFire also has the ability to scale your web dynodes, not just your working dynodes.

Both services have the ability to handle many tasks in parallel, as both Heroku and SimpleWorker are rated in the second of what I understand. So, if you deploy 10 working dynes in 6 seconds or 1 in 60 seconds, it doesn't matter (or barely) in costs.

I have not used SimpleWorker since the release of HireFire itself, which was a long time ago, so I’m not sure what else SimpleWorker can do these days or if they have simplified the process since then, so I’m not sure that the statements I made above are all still valid at this time.

Hope this helps!

Answer 2

Hi (founder of SimpleWorker),

Michael summed up pretty well, but I will add a few differences between Heroku Workers and SimpleWorker, not necessarily HireFire.

• Heroku has a maximum of 24 workers at a time, which means that only 24 jobs can be run immediately. With SimpleWorker, you can run 1000 immediately (and more as we grow) without any changes.
• Scaling with SimpleWorker is effortless, as your application grows, you don’t need to change anything, just keep throwing more jobs in our path.
• Geroku accuses you of using workers or not, SimpleWorker does not. This is a problem that HireFire solves, although it is not a problem if you use HireFire.
• SimpleWorker has built-in scheduling , so you don't need cron or anything else to get started.
• Management interface so that you can visualize all your employees / tasks, find errors, receive error warnings, view logs for all your tasks, etc.

The downside is that using SimpleWorker takes a little longer, since it does not start the entire Rails environment. You must think that your employees are separate entities working on a different system (as they are). For simple things like sending emails in the background or downloading some things from your interface here and there, Heroku workers are probably a good choice. If you carry out large batch tasks, planning, lengthy work tasks, want more visibility in your tasks, etc., then you can try SimpleWorker.

Btw, we recently released some new videos so you can understand how it works and how easy it is to use: http://www.simpleworker.com/how_it_works/videos

Hope this helps! And feel free to ask me any questions about SimpleWorker.

Answer 3

I use the delayed work, and then complete the rake task that I use to scale my hero workers based on whether there is delayed_job in my database:

 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 

With the addition of a scheduler, I can check my employees every 10 minutes to reduce costs.

I like this solution because I can use DelayedJob (which I am familiar with), and instead of using another plugin or third party, all I need is one simple rake task to limit Heroku costs and essentially pay only for that what i use.