Learnings from using Puma in production on Heroku

http://blog.codeship.io/2013/10/16/unleash-the-puma-on-heroku.html

by oBeLx • 13 years ago

55 9 13 years ago

blog.codeship.io

tjbiddle• 13 years ago

Puma has been great! I switched to it for both development and production on all of my Rails apps a week or so ago and haven't looked back.

matlock2• 13 years ago

Yes it even works very well on MRI. Definitely a good choice

jasdeepsingh• 13 years ago

Shameless plug: I've been moving over my own apps to Puma lately and definitely noticed improvements in performance without switching VM (we've used MRI so far). Lately, even did a small blog post on the topic:

http://jasdeep.ca/2013/07/deploying-rails-apps-with-puma-and...

This should get you started on non-Heroku platforms with Puma & Rails, well for development & staging purposes. I still have to do a post on setting up Puma for actual production deployments.

kbd2• 13 years ago

FTA:

We are still using MRI 2.0.0-p195 on Heroku and haven’t switched to either JRuby or Rubinius. Although there is a lot performance we could gain from this switch we are happy with the performance we have and it would make our development more complicated.

From the Rubinius 2.0 release post[1]:

Evan created Puma to meet the need for a fast web server that would promote the Rubinius parallel thread support. Puma also works well on MRI and JRuby. It provides Ruby applications excellent performance and multi-core scaling, especially when there's no global interpreter lock.

I'm very interested to see how much performance they would gain by switching to Rubinius, and why they say it would complicate their development.

[1] http://rubini.us/2013/10/04/rubinius-2-0-released/

matlock2• 13 years ago

We would probably get a good amount of better performance out of it, but our current Heroku bill is low enough that even cutting it in half would be a small thing compared to changing the ruby version every developer uses.

While technically interesting, it just doesn't make any sense for us from a business perspective to put time into it.

I bet it would be a lot faster though. At least it is according to all the performance measurements I've seen in the past.

jrochkind13• 13 years ago

To the extent it's about the GIL or lack thereof, I am confident that the amount of performance increase you would get by switching would be directly correlated with how much of your typical response generation time is spent waiting on I/O.

The _less_ time you spend waiting on I/O (you are cpu-bound), the _more_ performance increase you get from switching to an interpreter without a GIL.

Most of my web apps spend a very large percentage of their time waiting on I/O (chiefly an rdbms), but if you have a heavily optimized app that is more cpu-bound, you would see larger gains from a GIL-less interpreter.

This hypothesis just makes sense, and I also believe there's evidence for it in the benchmarking I did at: https://github.com/jrochkind/fake_work_app

kbd2• 13 years ago

Thanks for those benchmarks!

You get a big boost by using multiple Puma workers on MRI. Under Rubinius you should be able to only use one Puma worker for max performance, right?

I'd love to see benchmarks with Rubinius... ;)

Learnings from using Puma in production on Heroku

Related Stories