Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Puma, a fast concurrent web server for Ruby

puma.io

Post reply on HN
Print view View original

21–30 of 86 posts

Re: Puma, a fast concurrent web server for Ruby

#24

Post by waylonrobert »

JiPi wrote: post #21

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

Agreed. I also recall seeing it on HN before, and not that long ago.

Re: Puma, a fast concurrent web server for Ruby

#26

Post by JiPi »

mrinterweb wrote: post #23

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.

Is passenger the most popular? Is there any reliable statistics available somewhere?

Re: Puma, a fast concurrent web server for Ruby

#27

Post by jrochkind1 »

gavingmiller wrote: post #3

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

I attempted to do some generic benchmarking of just this question and found Puma way outperformed Unicorn under heavy load if your request processing are largely io-bound.

Didn't get much attention when I tried to post it to HN when I did it a couple months ago:

https://github.com/jrochkind/fake_work_app/blob/master/READM...

Re: Puma, a fast concurrent web server for Ruby

#28

Post by jrochkind1 »

nixme wrote: post #7
enoptix wrote: post #4

Earlier quoted context omitted.

Much better memory usage and (for us at least) better concurrency. We could only run 4 unicorn workers on a single dyno. But with Puma we run 16 threads with ease.

Have you tried running 3 or even 4 puma workers (each with 8-16) threads on a dyno? That way you can get more concurrency on CPU-bound requests in addition to IO-bound concurrency (assuming MRI).

I tried that in my attempt at benchmarking a standardized app on heroku, and, yep, it works great:

https://github.com/jrochkind/fake_work_app/blob/master/READM...

Re: Puma, a fast concurrent web server for Ruby

#29

Post by bretpiatt »

waylonrobert wrote: post #24
JiPi wrote: post #21

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

Agreed. I also recall seeing it on HN before, and not that long ago.

You may have seen a recent comment, looks like the main page was posted a year ago -- I relied on the URL duplicate checker when submitting it (it was new to me today to come across and I wanted to see thoughts from the HN community on it).

I ran a the search and found the previous:

   A modern, concurrent web server for ruby (puma.io)
   16 points by kachhalimbu 1 year ago | 2 comments | cached

Re: Puma, a fast concurrent web server for Ruby

#30

Post by jrochkind1 »

cmer wrote: post #17
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.

When I tried to benchmark a standardized app under MRI, I found that Puma works great _if_ your app is io-bound as opposed to cpu-bound.

This makes sense because multi-threading is still a win under MRI even with the GIL, only so long as your app is io-bound (so threads can be switched out when waiting on io, for instance waiting on a db query).

Most web apps I've worked with tend to be io-bound.

https://github.com/jrochkind/fake_work_app/blob/master/READM...

Post reply on HN