Free background jobs on heroku
Rails + Sidekiq with a single heroku dyno
Sidekiq is a gem for background jobs and a great alternative to Resque or DelayedJob. To set it up with a rails app on heroku normally requires an extra worker process.
You can avoid the need for an extra dyno by using unicorn as your webserver. Unicorn lets you spawn your sidekiq workers within your web dyno.
Sidekiq your web dyno!
if your Profile looks like this
web: bundle exec unicorn -p $PORT -E $RACK_ENV -c ./config/unicorn.rbthen just add something like the following to your config/unicorn.rb
before_fork do |server, worker|
@sidekiq_pid ||= spawn("bundle exec sidekiq -c 2")
endRedis connection limitation
If you are using sidekiq with heroku's redis-to-go nano addon you might also need to tweak you sidekiq concurrency and connection size to not max out nano's 10 connections limit. (see this blog post for details)
Here are some settings I use on a small app in production on heroku with three unicorn worker processes, sidekiq concurrency set to two (see bundle exec sidekiq -c 2 above) and redis-to-go's nano plan. I did not really fiddle around with it much - it works without problems so far for me.
config/unicorn.rb
worker_processes 3
after_fork do |server, worker|
Sidekiq.configure_client do |config|
config.redis = { :size => 1 }
end
Sidekiq.configure_server do |config|
config.redis = { :size => 5 }
end
endAlternative
You can also use something like sucker_punch. It does all the work within your rails process itself whereas Sidekiq runs as a separate long-running process, independent from your Rails process.
Written by dommmel
Related protips
17 Responses
@linjunpop - I mentioned sucker_punch in the last paragraph "Alternatives". Anything particular you wanted to say?
@dommmel Oh, Sorry. I guess I had Evernote an old version of this tip.
Very nice! I was wondering if there was an alternative to the two dynos on heroku. I'll give a try
How would you handle if the process dies? Heroku won't notice & bounce your dyno and Unicorn doesn't notice either.
@jalada Good question. I guess you could use Process.waitpid in some way... haven't done it myself
I actually implemented it. Time will tell if it works for sure. This kills the parent process as well, which on Heroku will bounce your entire dyno (which is what I wanted):
@worker_pid = spawn('bundle exec sidekiq')
t = Thread.new {
Process.wait(@worker_pid)
puts "Worker died. Bouncing unicorn."
Process.kill 'QUIT', Process.pid
}
# Just in case
t.abort_on_exception = trueThe idea of using Thread.new { Process.wait() } comes from the implementation of Process.detach, which is essentially the same.
@jalada Cool - please keep us updated on how it works out
Hi guys,
@jalada @dommmel did it work?
Hi, how can this be done with Puma? Concurrency noob here
looks like it to me - here is my puma.rb using 2 workers. Not tested under load just yet - and make sure you have you don't hit your db and redis connection limits.
environment ENV['RACK_ENV']
workers 2
threads 2,5 # 4-6
preload_app!
on_worker_boot do
@sidekiq_pid ||= spawn("bundle exec sidekiq -c 2")
end
Thanks for the tip. You mentioned sucker punch as an alternative but am I right in thinking that with sucker punch, I wouldn't be able to start a job from a rake task (heroku scheduler, for instance) or some other scheduling job and run it in the background of one of the existing heroku dynos?
Does worker perform even when the Heroku app goes to sleep?
@matixmatix Set up the New Relic plugin to ping your server periodically and it will always be awake!
great tip!
HERE BE DRAGONS!
I did this and it caused connections to my postgres database to build up on deploys and then took my site down. Use with caution!
I think you meant Procfile, not Profile.
