Hacker News Reader

Comment by Legion | Hacker News Reader

> you are using Unicorn, right? You should be!

Heroku Ruby guy here. I recommend Puma. Especially if your app is threadsafe. Even if it isn't you can still run multiple workers and only one thread and you get protection against slow clients (that Unicorn doesn't have). https://devcenter.heroku.com/articles/deploying-rails-applic...

I also wrote this gem that tunes the number of Puma workers and resets any workers where a memory leak is detected: http://github.com/schneems/puma_auto_tune

I admire your recent work with threads in Ruby with the Puma libraries and the threaded in memory queue (I was working on something similar myself, I keep forgetting to get back to it though). Most companies I see using Heroku are always wondering if their bill could be lower and most of the time they are using preforking servers and background job processors.

I look forward to your talk at Ancient City Ruby next week!

Wow, this is awesome. You should add a link to the Puma guide [1] as I've been wanting to make use of Puma workers for a while but have always been worried about running out of memory.

[1] https://devcenter.heroku.com/articles/deploying-rails-applic...

Any idea why the docs[1] recommend using Unicorn instead?

On Cedar, we recommend Unicorn as the webserver. Regardless of the webserver you choose, production apps should always specify the webserver explicitly in the Procfile.

[1]: https://devcenter.heroku.com/articles/ruby-support#rails-4-x...

Unsure how it is these days, but sometime back there were pretty huge issues with the rolling restart function (cluster mode pretty much didn't work, and would cause downtime) and UNIX socket handling in Puma (would hold onto sockets, would have to login to servers to clear the issue). This caused a decent bit of downtime on occasions.

I would expect these to be fixed by now, and for certain setups it simply wouldn't be an issue, but definitely put a bit caveat in "Use Puma!"

Performance wise we saw it actually be worse than Unicorn at my former company. There were a few issues but the biggest one was no out of band GC at the time, so GC time was part of the requests and something a user saw. There were some use cases where it should have destroyed Unicorn but still strangely lagged (threaded, high IO operations. Should have been able to do far more with less since Puma continues to serve while Unicorn workers will wait). Memory usage did seem better.

We ended up back on Unicorn after a few weeks of fighting. I would imagine it to be better now (no longer deal with servers at all, so no idea), but I found the dissonance between everyone heaping love on Puma at the time and the actual experience jarring.

It seemed like a fantastic project, but at the time only for certain projects and certain infrastructure setups while Unicorn was fairly bulletproof.

Of course all of this is old knowledge and with the people who are involved in the project I expect things are far better these days. Caveat lector and such. :D

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.

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

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

Puma really is great. I was floored by the performance gains compared to two unicorn workers.

I have a question regarding the Puma architecture.

Does it use async/evented connection handling combined with a thread pool of workers handling requests?

Why is Puma better than Unicorn?

Reply on news.ycombinator.com