Puma, a fast concurrent web server for Ruby
1–10 of 86 posts
Re: Puma, a fast concurrent web server for Ruby
#2We (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's pretty amazing how a single instance running Puma replaces an entire cluster of Unicorn workers.
p.s. We are also hiring Ruby, and iOS folks. Contact information is in my profile.
Re: Puma, a fast concurrent web server for Ruby
#3Can anyone who's used Puma on Heroku comment on how it compares to Unicorn?
Re: Puma, a fast concurrent web server for Ruby
#4Can anyone who's used Puma on Heroku comment on how it compares to Unicorn?
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.
Re: Puma, a fast concurrent web server for Ruby
#5Can anyone who's used Puma on Heroku comment on how it compares to Unicorn?
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.
Thanks, this is all very relevant at the moment. Trying to optimize page load times for a Heroku Rails app. Web server is one of the bottlenecks.
Re: Puma, a fast concurrent web server for Ruby
#6I'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?
Re: Puma, a fast concurrent web server for Ruby
#7Can anyone who's used Puma on Heroku comment on how it compares to Unicorn?
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).
Re: Puma, a fast concurrent web server for Ruby
#8I'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?
Sounds more like a problem with your implementation. I'm pretty sure Puma can handle SSE just fine. Your implementation probably depends on EventMachine which is not baked in like it is with Thin.
Re: Puma, a fast concurrent web server for Ruby
#9I'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?
Tenderlove has a blog post about SSEs using Puma. http://tenderlovemaking.com/2012/07/30/is-it-live.html
Re: Puma, a fast concurrent web server for Ruby
#10I'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?
Sounds more like a problem with your implementation. I'm pretty sure Puma can handle SSE just fine. Your implementation probably depends on EventMachine which is not baked in like it is with Thin.
I'm doing:
content_type "text/event-stream" stream(:keep_open) { |out| settings.connections From Sinatra, which I assume is then deferring to EventMachine, courtesy of Thin. I'll see if there's a way of forcing EM directly in to the Stream setup...thanks for the pointer.