3 ms·
We switched over to these shortly after they were available. The primary solution to the technical problem facing Rails apps on Heroku (made broadly known by th
by aculver 13y ago
We switched over to these shortly after they were available. The primary solution to the technical problem facing Rails apps on Heroku (made broadly known by the excellent Rap Genius blog posts) was to switch from the stock 'thin' web server to 'unicorn' or similar web server. 2X dynos make this solution even more effective, by providing two times the RAM which allows you to run more unicorn workers per process (e.g. from 2 to 4 for us) and have allowed us to reduce our Heroku bill by a couple hundred dollars a month. On top of that, the double CPU share means that workers will generally return the same results faster. It's sort of a no-brainer for Rails apps.
The other big win for us on Heroku recently was that Adept Scale came out of beta, which is a Heroku add-on which will monitor your traffic levels, response times, and related error rates and automatically scale up your dynos as needed. I'm not really sure why this isn't a core feature of the Heroku platform. We pay $36/mo. for Adept Scale, but they save us probably $200/mo, at least.
- ddorian43 13y agoa worker is a process in this case?
- aculver 13y agoYeah, I was a little confused by this at first because Heroku also has "workers" which are dynos provisioned to churn through queued background jobs, but unicorn "workers" are totally different: They're processes forked within the web dyno so a single server can process requests concurrently. Each forked process has the entire memory footprint of the Rails app (about 200-250 MB for us), so the more memory you have the more forked processes you can run on a single dyno. This reduces H12 errors because the more concurrency you have in a single process the less likely it is that Heroku's random routing layer is going to send a request to a dyno that is unable to handle the request because it's busy handling another long running request. As long as long running requests are the exception and not the rule, this should solve the problem.
- jplewicke 13y agoThere's also HireFire, which has support for scaling all your Heroku process types, not just your web processes: http://hirefire.io/ http://hirefire.io/ . I've used them for a few projects which honestly have never actually needed auto-scaling, but they're very easy to use overall and at $10/month are way underpriced. They do have a slower polling frequency (1 minute instead of 15 seconds) though.
- jwarzech 13y agoHireFire is fantastic (can't recommend it enough for people using Heroku). We use it at backstitch (http://backstit.ch http://backstit.ch) and it has saved us a ton of cash early-on.
- derengel 13y agoSo how do you handle slow clients? since Heroku doesn't do any caching and Unicorn is designed to server fast clients only.