Learnings from using Puma in production on Heroku
blog.codeship.io
blog.codeship.io
> 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.
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.
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
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... ;)
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!
...you _may_ seen performance improvements by having more than one worker even on jruby or rbx, without the GIL.
It would really have to be benchmarked, with some apps with realistic profiles.
But yeah, I'd expect the advantage of having more than one worker on rbx or jruby to be less. But it gets confusing.
(The ActiveRecord database connection pool is the prime example of such a shared-under-contention resource)
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.