Resque vs DelayedJob
Resque vs DelayedJob
How does Resque compare to DelayedJob, and why would you choose one over the other?
- Resque supports multiple queues
- DelayedJob supports finer grained priorities
- Resque workers are resilient to memory leaks / bloat
- DelayedJob workers are extremely simple and easy to modify
- Resque requires Redis
- DelayedJob requires ActiveRecord
- Resque can only place JSONable Ruby objects on a queue as arguments
- DelayedJob can place any Ruby object on its queue as arguments
- Resque includes a Sinatra app for monitoring what’s going on
- DelayedJob can be queried from within your Rails app if you want to add an interface
If you’re doing Rails development, you already have a database and ActiveRecord. DelayedJob is super easy to setup and works great. GitHub used it for many months to process almost 200 million jobs.
Choose Resque if:
- You need multiple queues
- You don’t care / dislike numeric priorities
- You don’t need to persist every Ruby object ever
- You have potentially huge queues
- You want to see what’s going on
- You expect a lot of failure / chaos
- You can setup Redis
- You’re not running short on RAM
Choose DelayedJob if:
- You like numeric priorities
- You’re not doing a gigantic amount of jobs each day
- Your queue stays small and nimble
- There is not a lot failure / chaos
- You want to easily throw anything on the queue
- You don’t want to setup Redis
In no way is Resque a “better” DelayedJob, so make sure you pick the tool that’s best for your app.