5 ms·

> you are using Unicorn, right? You should be! No. http://puma.io/ http://puma.io/

by Legion 13y ago

derwiki 13y ago
Are these numbers still accurate? http://ylan.segal-family.com/blog/2013/05/20/unicorn-vs-puma-redux/ 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.
- fomb 13y ago
  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.
  - rubiquity 13y ago
    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 :(
    - thinkbohemian 13y ago
      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!
      - midas007 13y ago
        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.
        evilduck 13y ago
        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. :)
        midas007 13y ago
        Sure. I even spawn other threads as ghetto thread supervision.
        midas007 13y ago
        Done, in the form of a reusable rails template. :) https://github.com/steakknife/rails41rc_plus_hacks_and_threads https://github.com/steakknife/rails41rc_plus_hacks_and_threa... Feedback requested in the issue tracker. Anything that seems out of place.
    - midas007 13y ago
      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.
  - bashcoder 13y ago
    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 http://www.slideshare.net/heroku/heroku-secrets-waza-2013
- thinkbohemian 13y ago
  > 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.
  - derwiki 13y ago
    Sorry, that's what I meant. Thanks for the detailed description of what I should have said.
    - thinkbohemian 13y ago
      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 :)
  - rubiquity 13y ago
    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 :(
    - thinkbohemian 13y ago
      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.
thinkbohemian 13y ago
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-applications-with-the-puma-web-server 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 http://github.com/schneems/puma_auto_tune
- rubiquity 13y ago
  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!
- jamesharker 13y ago
  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-applications-with-the-puma-web-server https://devcenter.heroku.com/articles/deploying-rails-applic...
- wasd 13y ago
  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-applications https://devcenter.heroku.com/articles/ruby-support#rails-4-x...
mikewhy 13y ago
Puma really is great. I was floored by the performance gains compared to two unicorn workers.
bnferguson 13y ago
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
otterley 13y ago
Why is Puma better than Unicorn?
cmbaus 13y ago
I have a question regarding the Puma architecture. Does it use async/evented connection handling combined with a thread pool of workers handling requests?

> you are using Unicorn, right? You should be! No. http://puma.io/ http://puma.io/

by Legion 13y ago

> you are using Unicorn, right? You should be! No. http://puma.io/ http://puma.io/

Are these numbers still accurate? http://ylan.segal-family.com/blog/2013/05/20/unicorn-vs-puma-redux/ 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.

fomb 13y ago
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.
- rubiquity 13y ago
  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 :(
  - thinkbohemian 13y ago
    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!
    - midas007 13y ago
      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.
      - evilduck 13y ago
        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. :)
        midas007 13y ago
        Sure. I even spawn other threads as ghetto thread supervision.
        midas007 13y ago
        Done, in the form of a reusable rails template. :) https://github.com/steakknife/rails41rc_plus_hacks_and_threads https://github.com/steakknife/rails41rc_plus_hacks_and_threa... Feedback requested in the issue tracker. Anything that seems out of place.
  - midas007 13y ago
    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.
- bashcoder 13y ago
  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 http://www.slideshare.net/heroku/heroku-secrets-waza-2013
thinkbohemian 13y ago
> 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.
- derwiki 13y ago
  Sorry, that's what I meant. Thanks for the detailed description of what I should have said.
  - thinkbohemian 13y ago
    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 :)
- rubiquity 13y ago
  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 :(
  - thinkbohemian 13y ago
    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.

thinkbohemian 13y ago

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-applications-with-the-puma-web-server 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 http://github.com/schneems/puma_auto_tune

rubiquity 13y ago
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!
jamesharker 13y ago
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-applications-with-the-puma-web-server https://devcenter.heroku.com/articles/deploying-rails-applic...
wasd 13y ago
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-applications https://devcenter.heroku.com/articles/ruby-support#rails-4-x...

mikewhy 13y ago

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

bnferguson 13y ago

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

otterley 13y ago

Why is Puma better than Unicorn?

cmbaus 13y ago

I have a question regarding the Puma architecture. Does it use async/evented connection handling combined with a thread pool of workers handling requests?