Puma, a fast concurrent web server for Ruby

Anyone used Puma on Heroku? Is it as simple as [1] or is there more configuration required [2] as is the case with Unicorn [3]?<p>[1] <a href="http://blog.steveklabnik.com/posts/2013-02-24-using-puma-on-heroku" rel="nofollow">http:&#x2F;&#x2F;blog.steveklabnik.com&#x2F;posts&#x2F;2013-02-24-using-puma-on-...</a><p>[2] <a href="http://www.subelsky.com/2012/10/setting-up-puma-rails-on-heroku.html" rel="nofollow">http:&#x2F;&#x2F;www.subelsky.com&#x2F;2012&#x2F;10&#x2F;setting-up-puma-rails-on-her...</a><p>[3] <a href="https://devcenter.heroku.com/articles/rails-unicorn" rel="nofollow">https:&#x2F;&#x2F;devcenter.heroku.com&#x2F;articles&#x2F;rails-unicorn</a>

Can someone with more webserver knowledge please explain how puma works from a high level? I know very little about web servers so the following may not even make sense!<p>I have looked at the source, and it appears a thread pool will listen to incoming requests, and pass them to a reactor then move on to handle more requests. Another thread polls the sockets and writes the data to the response stream when ready. [Note: this all may be completely wrong!]<p>If the way the server works as above is correct, does it mean it&#x27;s possible to achieve event-loop-based levels of concurrent connections along with good old CPU concurrency as well?

I like puma, but I thought it was interesting that the left passenger out of their performance graphs. Seems odd to omit the most popular ruby application server from the results.

Out of curiosity, why today?<p>I mean, this is not new at all, there is no major version that was released AFAIK...<p>This is great to share that though, just curious why it&#x27;s on HN today? :)<p>Edit: typo fix.

I&#x27;m not a Rubyist, but if I&#x27;m reading the section of the README that describes the design [1] correctly, the closest Python equivalent (architecturally speaking) is Waitress [2].<p>[1] <a href="https://github.com/puma/puma#built-for-speed--concurrency" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;puma&#x2F;puma#built-for-speed--concurrency</a><p>[2] <a href="http://docs.pylonsproject.org/projects/waitress/en/latest/design.html" rel="nofollow">http:&#x2F;&#x2F;docs.pylonsproject.org&#x2F;projects&#x2F;waitress&#x2F;en&#x2F;latest&#x2F;de...</a>

Looks good. It would be nice to see it on the Web Framework Benchmarks (<a href="https://github.com/TechEmpower/FrameworkBenchmarks" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;TechEmpower&#x2F;FrameworkBenchmarks</a>).<p>Edit: someone created an issue asking for contributors: <a href="https://github.com/TechEmpower/FrameworkBenchmarks/issues/459" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;TechEmpower&#x2F;FrameworkBenchmarks&#x2F;issues&#x2F;45...</a>

Any reason why thin is not in the comparison? Is it not very fast compared to the others in the chart?

We (ShopKeep) are using Puma for our thin web-services around our platform. Specifically, we send all of our data to a two nodes load-balanced running Puma for our analytics aggregation. It&#x27;s pretty amazing how a single instance running Puma replaces an entire cluster of Unicorn workers.<p>p.s. We are also hiring Ruby, and iOS folks. Contact information is in my profile.

I&#x27;ve been using Puma in dev&#x2F;QA and it&#x27;s impressive. I&#x27;m planning on trying it out in production but have a lot invested in Unicorn at the moment. For example, I have monit confs that kill workers once they reach a certain memory threshold and I&#x27;ll have to figure out how to do that with Puma.

I&#x27;m one of the authors behind Phusion Passenger (<a href="https://www.phusionpassenger.com/" rel="nofollow">https:&#x2F;&#x2F;www.phusionpassenger.com&#x2F;</a>), a polyglot web server for Ruby, Python and Node.js.<p>We&#x27;ve recently written a comprehensive comparison between Puma and Phusion Passenger, which you can read here: <a href="https://github.com/phusion/passenger/wiki/Puma-vs-Phusion-Passenger" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;phusion&#x2F;passenger&#x2F;wiki&#x2F;Puma-vs-Phusion-Pa...</a> The comparison covers things like concurrency models, I&#x2F;O models, security, clustering, multi-app support, documentation, memory usage, performance and more. Although the comparison is between Puma and Phusion Passenger, a lot of the points are relevant to a Unicorn-Puma comparison as well.

Just keep in mind your code (and gem&#x27;s code) needs to be thread safe.

Less memory usage then Unicorn here, though we recently moved to Passenger enterprise which is really similar: <a href="https://www.phusionpassenger.com/enterprise" rel="nofollow">https:&#x2F;&#x2F;www.phusionpassenger.com&#x2F;enterprise</a><p>good writeup on the subject here: <a href="https://github.com/phusion/passenger/wiki/Puma-vs-Phusion-Passenger" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;phusion&#x2F;passenger&#x2F;wiki&#x2F;Puma-vs-Phusion-Pa...</a>

I&#x27;ve been enjoying using Puma in clustered mode for some production sites, but falling back to Thin for Server Sent Events (new EventSource()) - does anyone know if this is ever likely to come to Puma, or is there a fundamental reason that the Puma process model can&#x27;t support SSE?

Well. I have just come across this one which says Unicorn to be the best performing one. Apparently, Puma proves wrong even with multiple workers.<p><a href="https://gist.github.com/pbyrne/5218411" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;pbyrne&#x2F;5218411</a>

Can anyone who&#x27;s used Puma on Heroku comment on how it compares to Unicorn?

I&#x27;m running Puma on my RaspberryPi for a pet Rails app and it&#x27;s incredibly fast. Would recommend.

Is it just me beeing blind, or does it not support https?

Puma is not for me, but Ragel seems very interesting.