This is the blog for Scout, Enterprise-grade server monitoring without the bloat.
70+ plugins, realtime charts, alerts, and Chef/Puppet-friendly configuration.

Three reasons for Resque (and a Scout Plugin)

Posted in Plugins | Comments Comments

Jesse Newland has created a Scout Plugin for monitoring Resque, a Redis-backed background processing library. While I’d love to write poetically about the plugin, it’s actually dirt-simple and the meat of the plugin is just 14 lines of code. Just click to install the plugin within Scout and you’re monitoring Resque.

The big question: why Resque? There are already production-proven background processing systems out there for Ruby developers. Jesse and the crew at Rails Machine manage a large number of customers and using different background processing libaries across apps can make things more complicated.

Rather than ponder the question, I asked Jesse. Being the nice guy he is, Jesse was happy to give three reasons why they’ve started using Resque at Rails Machine.

I’ve added the sub-text beneath his main points so blame me for any broken analogies.

1. The memory-leak resistant forking model is smart

Resque is like the cranky mom in Adam Sandler’s They’re all going to laugh at you! album. It assumes the worst. Your background jobs? They are going to lock up, leak memory, or run too long. Everyone will sit back and laugh at you.

Really, can you do anything right?

Resque uses a parent/child model. It ensures that leaky jobs release memory upon completion and you can tell the parent to kill a child if it is taking too long.

2. Resque comes with a super-sexy built in UI

It’s easy to check the current status of Resque with its built-in Sinatra-backed web UI.

3. Process jobs without impacting a database server

For many web applications the database is the bottleneck. A job queue with hundreds of thousands of jobs will only thrash the database server more. Because Resque is backed by Redis, an in-memory database, the queues are maintained in memory and not on disk.

So, should I use Resque instead of DelayedJob?

Many of us aren’t processing a huge workload. DelayedJob works great and is simple to setup. GitHub, where 50% of the workload happens in the background, survived for a while on DelayedJob. That’s a strong endorsement.

However, it’s good to know there’s another way if your job queue gets feisty.

Elsewhere

Comments

blog comments powered by Disqus
comments powered by Disqus