Any reason why thin is not in the comparison? Is it not very fast compared to the others in the chart?
Puma, a fast concurrent web server for Ruby
31–40 of 86 posts
Re: Puma, a fast concurrent web server for Ruby
#32Can 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 pr…
What did you use for profiling? Their newrelic add-on?
Re: Puma, a fast concurrent web server for Ruby
#33Well. I have just come across this one which says Unicorn to be the best performing one. Apparently, Puma proves wrong even with multiple workers. https://gist.github.com/pbyrne/5218411
Interesting goes against directly what they claim on their own page. Its tested on a four core machine. I'm suspecting the 16 default threads were the problem, since Unicorn only ran with 4 processes not 16.
Re: Puma, a fast concurrent web server for Ruby
#34Can 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…
I'm one of the authors behind Phusion Passenger (https://www.phusionpassenger.com/), a polyglot web server for Ruby, Python and Node.js.
What you said is basically correct. And yes, it is possible to combine event loops with threads in the way you described to get CPU concurrency as well. Whether it is actually helpful depends on the use case. The Phusion Passenger core is evented (similar to Nginx and Node.js) since version 4.0. We considered a multithreaded-evented architecture as well, but it turned out to be less beneficial than we hoped because the applications themselves use plenty of CPU already, and because we rely on shared in-memory state for proper load balancing between processes, thus having a source of contention. In the end, the single-threaded evented architecture in Phusion Passenger turned out to be more than enough.
Re: Puma, a fast concurrent web server for Ruby
#35I'm one of the authors behind Phusion Passenger (https://www.phusionpassenger.com/), a polyglot web server for Ruby, Python and Node.js.
We've recently written a comprehensive comparison between Puma and Phusion Passenger, which you can read here: https://github.com/phusion/passenger/wiki/Puma-vs-Phusion-Pa... The comparison covers things like concurrency models, I/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.
Re: Puma, a fast concurrent web server for Ruby
#36I 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.
All of the servers listed here are standalone servers, while Passenger is a module for existing servers. I don't really see why you couldn't include Passenger here, but it seems like they're only comparing like to like, which I guess is fair.
Re: Puma, a fast concurrent web server for Ruby
#37Can 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…
I'm looking at the 'Puma' section in Jesse Storimer's book "Working With TCP Sockets" and that seems to be the general idea behind it... uses a thread pool for concurrency, monitors persistent connections with an evented reactor.
I'm not affiliated with the author, but this was such a nice book to get an intro to webservers and their architectures/tradeoffs from.
Really fueled my love of sockets :)
Re: Puma, a fast concurrent web server for Ruby
#38Earlier quoted context omitted.
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.
I'm one of the authors behind Phusion Passenger (https://www.phusionpassenger.com/), a polyglot web server for Ruby, Python and Node.js.
We recently wrote a demo demonstrating SSE on Phusion Passenger (https://github.com/phusion/passenger-ruby-server-side-events...). During writing of this demo, we found out that sinatra-contrib's streaming code relies on EventMachine. That means that sinatra-contrib's streaming only works on EventMachine-based servers, like Thin and on Goliath.
Based on my knowledge about Puma, I'm pretty sure SSE works fine on Puma as well. The Phusion Passenger SSE demo uses the Rack socket hijacking API (which we've blogged about: http://blog.phusion.nl/2013/01/23/the-new-rack-socket-hijack...) to implement SSE. This approach should work on Puma as well because it supports the Rack socket hijacking API too.
Re: Puma, a fast concurrent web server for Ruby
#39Earlier quoted context omitted.
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
Fair enough. Just thought I might have missed something new and big! :)
Re: Puma, a fast concurrent web server for Ruby
#40Can 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...
Your application is not fair at all. It looks like your sleep mimics I/O boundedness, but in reality it does nothing but set an arbitrary request length. In a real world application I/O requests contend for resources with eachother. Sleep calls don't contend with each other at all.
This means that application servers can just keep stacking concurrent requests with perfect performance. If there was actually I/O being done that took 250ms, then you would find that it was the real bottleneck, and it would be the dominant factor in your benchmark, with the differences between app servers all but disappearing.