Delayed Job is great for small apps, it’s work out-of-the-box with ActiveRecord, you can also plug it into mongoid and it’s probably your first choice if you don’t want to setup redis. But when your traffic gets higher and higher, and you have to do more background jobs it’s becoming clear it’s not the perfect solution - the database-lock mechanism just don’t play very well with high amount of tasks.

Migrating to resque shouldn’t be a big problem (well, I guess it’s vary greatly, depending of you app specifics), I will provide here some quick tips, as usual:

• configuring redis isn’t so complicated as it seems, provided example (I recommend sticking to current branch 2.6) is very well documented and should be self-explanatory

• keep in mind that job arguments are JSON encoded, so all hashes will became strings

• converting jobs structure and enqueue calls should also be straight-forward, if you have some heavily customized jobs take a look at hooks that resque has to offer - they are quite similar to the ones from delayed_job, so you shouldn’t have much of a problem converting those

• you can replace delayed_job_web with built-in resque back-end. Just add to your routes:

{% codeblock config/routes.rb %} mount Resque::Server, :at => “/resque” {% endcodeblock %}

You will probably want to protect it with some kind of password using initializer:

{% codeblock config/initializers/resque.rb %} unless Rails.env.development? Resque::Server.use Rack::Auth::Basic do |user, password| user == ’login’ && password == ‘password’ end end {% endcodeblock %}

• if you need some simple capistrano integration - take a look at capistrano-resque

• I also recommend checking out resque-scheduler, especially if you have a lot of tasks scheduled in you crontab - moving them to your app repository should make it a little bit more clear what’s really going on

And one final note - resque 2.0 is currently heavy development, you you might want to stick to 1-x-stable branch.