Puma, a fast concurrent web server for Ruby • Hacker News Board

Re: Puma, a fast concurrent web server for Ruby

#11

Post by j4mie » Tue, Aug 27, 2013, 2:06 PM UTC

I'm not a Rubyist, but if I'm reading the section of the README that describes the design [1] correctly, the closest Python equivalent (architecturally speaking) is Waitress [2].

[1] https://github.com/puma/puma#built-for-speed--concurrency

[2] http://docs.pylonsproject.org/projects/waitress/en/latest/de...

Re: Puma, a fast concurrent web server for Ruby

#12

Post by purephase » Tue, Aug 27, 2013, 2:08 PM UTC

I've been using Puma in dev/QA and it's impressive. I'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'll have to figure out how to do that with Puma.

Re: Puma, a fast concurrent web server for Ruby

#13

Post by nlh » Tue, Aug 27, 2013, 2:10 PM UTC

gavingmiller wrote: post #3

Can anyone who's used Puma on Heroku comment on how it compares to Unicorn?

I switched from Unicorn to Puma for my relatively low-load Heroku-based Rails app and have seen nothing but improvements across the board. Less memory usage, lower response times, overall better performance. It's working very well.

Note: I'm an amateur and I know I'm not nearly optimized across many areas -- the app could be better, I'm not using JRuby (where multi-threaded shines, or so I read), so this is from a pretty novice perspective. But from here, Puma has been great.

Re: Puma, a fast concurrent web server for Ruby

#14

Post by cmelbye » Tue, Aug 27, 2013, 2:21 PM UTC

gavingmiller wrote: post #3

Can anyone who's used Puma on Heroku comment on how it compares to Unicorn?

Puma works great on Heroku. Rubinius, on the other hand, doesn't. It was incredibly slow, the app took more than a minute to boot up which caused Heroku to think it crashed. However, you can still use Puma with MRI 1.9.3 or something else and it'll still work great.

Re: Puma, a fast concurrent web server for Ruby

#15

Post by sleepyhead » Tue, Aug 27, 2013, 2:25 PM UTC

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]?

[1] http://blog.steveklabnik.com/posts/2013-02-24-using-puma-on-...

[2] http://www.subelsky.com/2012/10/setting-up-puma-rails-on-her...

[3] https://devcenter.heroku.com/articles/rails-unicorn

Re: Puma, a fast concurrent web server for Ruby

#16

Post by facorreia » Tue, Aug 27, 2013, 2:26 PM UTC

Looks good. It would be nice to see it on the Web Framework Benchmarks (https://github.com/TechEmpower/FrameworkBenchmarks).

Edit: someone created an issue asking for contributors: https://github.com/TechEmpower/FrameworkBenchmarks/issues/45...

Re: Puma, a fast concurrent web server for Ruby

#17

Post by cmer » Tue, Aug 27, 2013, 2:30 PM UTC

justkez wrote: post #6

I'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't support SSE?

Are you doing so with MRI/Ruby 2.0? Been considering Puma over Unicorn since it works so well for one of our JRuby apps but was wondering about how it would perform on MRI since it seems like it was never really designed with MRI in mind.

Re: Puma, a fast concurrent web server for Ruby

#18

Post by allr » Tue, Aug 27, 2013, 2:30 PM UTC

Less memory usage then Unicorn here, though we recently moved to Passenger enterprise which is really similar: https://www.phusionpassenger.com/enterprise

good writeup on the subject here: https://github.com/phusion/passenger/wiki/Puma-vs-Phusion-Pa...

Re: Puma, a fast concurrent web server for Ruby

#19

Post by amarraja » Tue, Aug 27, 2013, 2:45 PM UTC

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!

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!]

If the way the server works as above is correct, does it mean it's possible to achieve event-loop-based levels of concurrent connections along with good old CPU concurrency as well?

Re: Puma, a fast concurrent web server for Ruby

#20

Post by vicentereig » Tue, Aug 27, 2013, 2:46 PM UTC

sleepyhead wrote: post #15

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]? [1] http://blog.steveklabnik.com/posts/2013-02-24-using-puma-on-... [2] http://www.subelsky.com/2012/10/setting-up-puma-rails-on-her... [3] https://devcenter.heroku.com/articles/rails-unicorn

I'm actually using it in a small side-project I implemented a couple of weeks ago. (http://playas.io) It uses Rails 4 [0], JRuby 1.7.4, postgresql with full text search, one dyno and 10 workers.

It is not the first time I'm using JRuby and Puma, I must say I'm pretty happy with it.

I had enough with the official documentation, just tweaking the DB pool to fit in the Rediscloud free version constraints. [1]

https://devcenter.heroku.com/articles/concurrency-and-databa...

[0]: You'll need to download JCE 6 Extensions to get Puma, JRuby 1.7.4 and Rails 4 running in development: http://www.oracle.com/technetwork/java/javase/downloads/jce-...

[1]: Rediscloud free version gives you 10 connections.