Although the most common model for user interaction with a Rails system is the query → response pattern of a web service, it is often necessary or beneficial to be able to create processes on a web server or Rails application that run either at specified intervals, or continually in the background, performing automated tasks.
The built-in cron facility in most operating systems can be used to trigger execution of a Rails process at preset intervals.
For background processes that are only run at a long interval, the runner script allows the execution of a command within the full Rails environment. By default, the command will be executed in the development environment. To change the environment, use the ”-e” option.
For example:
# m h dom mon dow command 0 12 * * * /usr/local/bin/ruby /application/script/runner -e production 'User.deliver_updates'
The disadvantage of this method is that it incurs the full overhead costs of creating the Rails environment to run the single command. As such, it's okay for something that's run once a day, or even maybe once an hour, but using it more frequently than that will start to incur a serious overhead cost on the server. Common uses include updating static templates with the results of expensive database queries (e.g. “top ten lists”) and cleanup processes.
Delayed Job is a plugin extracted from Shopify by Rails Core Alum Tobias Lütke. It has received some attention from DHH, Rick Olson, and GitHub. GitHub posted some thoughts on Delayed Job and their god config on their blog.
Delayed Job does not suffer from the overhead of some other background processors (such as Backgroundjob), which require loading the entire Rails stack in order to run each job. Instead, you are supposed to leave at least one background processor running, which will pull jobs saved in your delayed_jobs database table (created with a migration).
The README and wiki provide some simple instructions for getting started.
Discussion