Skip to content
This repository

Network Architecture

I recommend running 1 or more Sidekiqs per app server in your production cluster. At The Clymb, we run two Sidekiqs on each of our three app servers, for six total processes. With default concurrency of 25, this gives us 150 worker threads. All six processes talk to the same master Redis server and we just use the default queue to keep things as simple as possible.

Running a separate utility instance or using multiple, prioritized queues adds complexity where it is not needed for us.

Capistrano

Use the capistrano-sidekiq gem. Integrated support has been removed.

Heroku

Using sidekiq with Heroku is simple, you need to use the (default) Cedar stack and add a Procfile to your Rails app to start a sidekiq worker process:

web: bundle exec unicorn ...
worker: bundle exec sidekiq ...

Before version 3.0 Sidekiq will automatically configure itself to use Redis-to-Go so you don't need to customize the Redis server location. Starting from 3.0 version the built-in support for Redis-to-Go is removed, you'll need to set heroku config:set REDIS_PROVIDER=REDISTOGO_URL env variable for it to work.

See this page for more details about Procfiles, Foreman and Heroku.

Daemonization

I strongly recommend people use a process supervisor like runit or upstart to manage Sidekiq (or any other server daemon) versus something simpler like nohup or the -d flag. This ensures Sidekiq will immediately restart if it crashes for some reason.

I've included the Upstart config The Clymb uses to manage our Sidekiq instances on our app servers. These files go in /etc/init and will automatically startup Sidekiq when the machine is booted. The Sidekiq process group can be very simply managed with [start | stop | restart] workers.

Something went wrong with that request. Please try again.