Optimizing Heroku

I spent some time recently playing with a trivial Rails 3 app using girl_friday and learned a few interesting things:

  • Michael’s post on using Unicorn with Heroku is a fantastic idea and great way to improve the efficiency of your Heroku application’s web dynos.
  • Heroku imposes a limit of 15 threads per Ruby process (there is an open question about this, it might just be a bug in the Heroku Cedar stack, which is still beta). If you are using thin, you get 1 process and 15 threads per dyno. If you are using Unicorn, you get 3 processes* and 45 threads. UPDATE: I don’t believe Heroku has a thread limit, just a memory limit.
  • girl_friday defaults to 5 threads per queue. With the thread limit on Heroku, you’ll want to carefully ration the size of each queue. girl_friday’s Rack status app can tell you at runtime which queues are busy and which are quiet for tuning purposes.
  • girl_friday can, in many cases, replace or dramatically reduce your need for separate worker dynos, saving you money.

* Where 3 is based on the memory consumption of your application. YMMV.

Unicorn appears to work great with girl_friday and Heroku’s free service level actually becomes useful for non-trivial applications with these optimizations. Know any other tips? Let me know!

8 thoughts on “Optimizing Heroku”

  1. These are some nice to know facts! Yeah, since Cedar it’s finally possible to deploy low-traffic / basic applications for a more affordable price.

    The only thing that still needs to be fixed is the SSL price. Though, I wonder how easy it’ll be since it’s a limitation that comes with EC2. Hopefully someone comes up with a solution to that and then I think I’ll find myself hosting a lot more with Heroku. Cause paying $20/mo (or even $100/mo) + $10/year for something you usually only pay $10/year for is quite harsh. Don’t blame Heroku though, and I believe they are looking for ways to reduce the cost of this. The SNI for $5/mo is a good price point if it were for either the hostname or ip-based solutions.


  2. girl_friday is a great replacement for “spawn” (eg https://github.com/rfc2822/spawn) for me – spawn seems to kill the heroku process and i can’t work out why. girl_friday is a great replacement for dealing with long jobs that would otherwise call a browser timeout. Thanks!

  3. Do you happen to know how this affects the Scheduler addon? It runs “one-off processes which will count toward your dyno-hours for the month.” If we can have multiple processes in a dyno using Unicorn, does that mean that it won’t spin up an additional dyno?

  4. Hi Mike,
    when calculating number of threads on heroku (Unicorn and let’s say 3 workers) – do we take 45 as a max number of threads for girl_friday queues or 15?
    Do these queues/threads distribute among unicorn processes or they all need to ‘fit’ in one process? Thx!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>