Learnings from using Puma in production on Heroku(blog.codeship.io)
blog.codeship.io
Learnings from using Puma in production on Heroku
http://blog.codeship.io/2013/10/16/unleash-the-puma-on-heroku.html
9 comments
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
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
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... ;)
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... ;)
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!
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!
Although to the extent that there may be some shared resources between threads, which may be shared under an architecture where the more threads you have contending for resources, there is a performance penalty....
...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)
...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)
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.
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.
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.
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.
> 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/