Hacker News Reader

Hacker News

Comment by derwiki | Hacker News Reader

Parent Full thread

derwiki

Are these numbers still accurate?

http://ylan.segal-family.com/blog/2013/05/20/unicorn-vs-puma...

At any rate, Unicorn would still be better than the default Heroku server.

View on HN

> the default Heroku server

There is no "default Heroku server" you get exactly what you specify. If you specify nothing you get what Rails runs by default which is webrick and happens to be awful in production. It's not that "Heroku has a bad default" here but rather Rails' default web server is not intended to run in Production. Most of our docs try to emphasize that you should be using another server other than webrick. Some people want to just bang out a proof of concept and not worry about configuring Puma or Unicorn, for them webrick is fine.

Sorry, that's what I meant. Thanks for the detailed description of what I should have said.

I understood the simplification to be for clarity of your point, not a misunderstanding. I just wanted to clear it up for any other readers :)

Does Heroku reach out to people that are running WEBrick in production? Or do you have a report or something showing how many are running WEBrick in production? I agree that it takes a lot of ignoring of warnings and documentation to run WEBrick in production, and Heroku's docs do a great job educating people, but nonetheless I meet people (usually 1-2 people startups where tech founder isn't very strong) that are running WEBrick in prod :(

We tend to make side optimization recommendations whenever we notice something is wrong and you open a support ticket. We could add it to the warnings at the end, but I can safely say most people don't read them. Still worth having for those that don't, good suggestion.

There is no 'default' Heroku server on Cedar, it runs what your app asks to run. If that's Thin you'll be running on Thin. However, Heroku recommend Unicorn.

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. :)

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

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.

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

Reply on news.ycombinator.com