

Learnings from using Puma in production on Heroku - oBeLx
http://blog.codeship.io/2013/10/16/unleash-the-puma-on-heroku.html

======
kbd
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/](http://rubini.us/2013/10/04/rubinius-2-0-released/)

~~~
jrochkind1
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](https://github.com/jrochkind/fake_work_app)

~~~
kbd
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... ;)

~~~
jrochkind1
Ah, good point. Yeah, in theory, I think that's true, you could get away with
only one worker on rubinius or jruby.

I'm mostly sticking with MRI, so I mostly think about the other side -- on MRI
you need multiple workers, yeah, but _even_ on MRI, you get a boost by using
multi-threads _on each worker_. This is the thing lots of people are
neglecting!

------
jasdeepsingh
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...](http://jasdeep.ca/2013/07/deploying-rails-apps-with-puma-and-nginx/)

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.

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

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

