I can't imagine why a company that charges a ton for RAM would recommend a preforking application server ;) Also, when using vCPUs versus using real CPUs there's a noticeable drop off in thread performance so I doubt Puma performs all that great on Heroku :(

I recommend Puma and work for Heroku, though threadafety is still a huge issue. It also pre-forks in hybrid mode which makes it super awesome. Also it takes care of slow clients!

It's also way, way cheaper in terms of ram.

We fire up sidekiq and clockwork in threads within the puma process rather than take ~ 100 MiB/process hit of running them separately.

Is there any blog post or tutorial you can point to that explains how to do that?

If not, I would love it if you wrote one. :)

Done, in the form of a reusable rails template. :)

https://github.com/steakknife/rails41rc_plus_hacks_and_threa...

Feedback requested in the issue tracker. Anything that seems out of place.

Sure. I even spawn other threads as ghetto thread supervision.

It might seem in their best intere$ts, but it was probably the most trusted rack server at the time they wrote the how-to article.

In fact, without specifying anything else, a Rails app deployed to Heroku will default to using webrick. Consequently, at Waza 2013 they revealed that webrick is the most used server at Heroku, and is 3x more popular than Thin. [0]

[0] http://www.slideshare.net/heroku/heroku-secrets-waza-2013