Puma, a fast concurrent web server for Ruby

by bretpiatt • 13 years ago

164 83 13 years ago

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'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.

gavingmiller• 13 years ago

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

enoptix• 13 years ago

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.

cpursley• 13 years ago

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.

nixme• 13 years ago

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).

nlh• 13 years ago

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.

hhenn2• 13 years ago

What did you use for profiling? Their newrelic add-on?

cmelbye• 13 years ago

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.

jrochkind14• 13 years ago

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...

tinco4• 13 years ago

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.

justkez2• 13 years ago

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?

andrewhavens• 13 years ago

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.

justkez2• 13 years ago

I'm doing:

content_type "text/event-stream" stream(:keep_open) { |out| settings.connections << out }

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.

evilduck• 13 years ago

Tenderlove has a blog post about SSEs using Puma. http://tenderlovemaking.com/2012/07/30/is-it-live.html

cmer• 13 years ago

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.

jrochkind14• 13 years ago

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...

j4mie• 13 years ago

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...

purephase• 13 years ago

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.

sleepyhead• 13 years ago

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

vicentereig• 13 years ago

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.

facorreia• 13 years ago

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...

allr• 13 years ago

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...

amarraja3• 13 years ago

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?

FooBarWidget16• 13 years ago

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.

cmbaus• 13 years ago

How does Passenger deal with blocking I/O from applications if it is single threaded? Does the entire event loop block while doing I/O?

amarraja3• 13 years ago

Thanks for the update. I'm likely going to try and deconstruct and rebuild some of it to really get my head around evented architectures -- will try and blog it. Years of threads had me in bliss until this non-blocking renaissance came along :)

hhenn2• 13 years ago

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 :)

amarraja3• 13 years ago

Thanks for reminding me about Jesse's book(s), I knew there was something I was meant to do!

JiPi4• 13 years ago

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.

waylonrobert• 13 years ago

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

bretpiatt• 13 years 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

JiPi4• 13 years ago

Just keep in mind your code (and gem's code) needs to be thread safe.

mrinterweb2• 13 years ago

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.

JiPi4• 13 years ago

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

mrinterweb2• 13 years ago

http://blog.planetargon.com/entries/2012/8/14/rails-hosting-...

chc2• 13 years ago

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.

tinco4• 13 years ago

You can use Passenger as a standalone server too, it's called Passenger Standalone. You can install it with 'gem install passenger', and run it by running 'passenger start'.

Bharath1234• 13 years ago

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.

https://gist.github.com/pbyrne/5218411

Bjoern• 13 years ago

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.

http://puma.io/

dsrw• 13 years ago

1 puma worker vs 4 unicorn workers isn't a fair test on a multi core machine under MRI.

chucknelson• 13 years ago

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

FooBarWidget16• 13 years ago

I'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.

nwienert• 13 years ago

You've done a great job posting Passenger links all over this thread.

I find it in poor taste come into a semi-related post and repeatedly spam links to your product over and over...

speleding• 13 years ago

My first thought upon reading the article was: "I wonder how this compares to Passenger?". I find it very helpful to get an authoritative link from the Passenger guys themselves in this thread.

Since Passenger is by now pretty much the default way to run a Ruby stack I don't think any one here doesn't know who they are and so they really do not need to spam. They are just contributing to the discussion and I appreciate that.

FooBarWidget16• 13 years ago

mwienert, my apologies if it came over as spamming. The reason why I put an introduction in those posts is because last time I posted comments about Phusion Passenger people told me that I should introduce myself as being an author of Phusion Passenger. And as you've noticed in this thread (and not just on HN, see e.g. http://stackoverflow.com/questions/18398626/why-did-gitlab-6...), I actually say some very favorable things about Puma, and I thought that people will appreciate it if they know that it came from someone who writes web servers instead of just some random commenter.

But I see your point, and I'll keep it in mind. If I can edit my other posts I would remove some links but unfortunate HN has already frozen them.

mrmondo2• 13 years ago

We just moved our ruby apps (puppet, Redmine,gitlab) from apache passenger to puma + nginx because passenger is awful - it's slow, bloated and it eats memory.

mrmondo2• 13 years ago

Ok sorry I re-read that and I sounded quite loaded, I was actually a bit miffed that someone from passenger posted on this puma thread but I suppose they have the right to.

We didn't have a great experience with passenger, it does seem bloated and we decided to move away from apache to nginx for similar reasons.

Tldr; We've been very happy with our move from passenger to puma.

moe4• 13 years ago

Please stop making your comparisons sound as if passenger-free was a fully functional application server such as unicorn or puma. It is not.

Passenger-free is a deliberately crippled demo-version. If someone wants to use passenger in production they will have to pay $50 USD per year, per server for it. And you know that very well.

The 'free' passenger drops requests and serves 502 errors to the users during every single deploy.

That's equivalent to popping up shareware nag-screens into my face at random intervals. Except phusion passenger doesn't nag me, it nags my customers.

You call the avoidance of these errors a 'feature' ('rolling restarts') that must be paid for.

For some reason your helpful comparisons never mention that both unicorn[1] and puma[2] ship with this basic functionality out of the box. One could almost think it is part of your sales strategy to have people notice this little 'limitation' only after they already deployed your product to production...

[1] http://www.justinappears.com/blog/2-no-downtime-deploys-with...

[2] http://blog.nicolai86.eu/posts/2013-02-06/phased-restarts-us...

ericb• 13 years ago

Most apps where you would be concerned with downtime have load balancers in front of them. This isn't burning fire you make out because you can pull one app server out of the pool, restart and then put it back in once it is restarted. We do this by using keepalived and renaming a chk.txt file in the root.

trustfundbaby3• 13 years ago

I think thats a little harsh.

I've been using Passenger since it was called Apache mod_rails http://www.concept47.com/austin_web_developer_blog/ruby-on-r... you have to remember that before the Phusion guys showed up, there was no easy way to run a rails server without proxying requests to mongrel, thin or something like that. instances could bloat in memory or die and your app could, for whatever reason, go down and you wouldn't know it. Did I mention that rails apps were also pretty slow back then?

They made deploying and maintaining rails an order of magnitude easier with Passenger, first with the mindblowingly simple installation process and later by introducing ideas like killing and spinning up new app instances after xxx requests, or spinning instances up or down depending on activity. All this with simple configuration switches out the box. Even the advances in Passenger 4 are pretty amazing (threaded mode, and out-of-band garbage collection, come to mind)

What I'm saying is, they've done a lot for the Rails ecosystem and while I'm not a fan of their new pricing strategy with Passenger or their marketing tack with Puma posts on this thread, I think its worthwhile to be a bit more gentle in chiding them because of their peerless contributions in the past ... plus their link is actually a very well written comparison

FooBarWidget16• 13 years ago

Moe, I don't understand where your hostility comes from. It is fine if you don't like Phusion Passenger, but please don't say things that are untrue.

The open source version of Phusion Passenger is not a crippled version. It is used in production by many large users, including New York Times, AirBnB, etc. Your statement that the open source version is "crippled" goes right against the fact that we've been actively developing the open source version ever since Enterprise came out. In fact, open source development has become more active after Enterprise than before, thanks to Enterprise funds. If you check our commits at Github you will see that the rate of development has accelerated. If you take a look at all the new features in the open source version of Phusion Passenger 4 you will see that it is improving at a tremendous rate.

It is not true that the open source Phusion Passenger drops requests and serves 502 errors to users on every single deploy. Upon touching restart.txt, the open source versions blocks requests and resumes them after having restarting 1 process. The blocking only happens for the first process, not for the ones after. At no point will requests be dropped or will errors be served. We even have integration tests in place to check for this. If you see request drops or errors in the open source version, please contact us and we'll have a better look at the problem. If it's a bug, we'll fix, it's that simple.

"popping up shareware nag-screens at random intervals" is completely false. There are absolutely no nag-screens in Phusion Passenger. The open source version of Phusion Passenger is open source, so if you don't believe me, then dig into the source code and tell me where exactly the nag screens are.

The lack of rolling restarts in the open source version is not a secret. Our documentation clearly mentions the differences between the open source and the Enterprise version. With a few clicks, you can find out what the open source version does and does not have.

And actually, the open source version does not "lack" rolling restarts, it just does not automate it for you. You can implement rolling restarts using Phusion Passenger Standalone (open source version!) in the same way you do with Thin and Mongrel, i.e. by swapping sockets. It works fine and some of our users do exactly this. It is just more work than the automated, polished, error-resistant version that Enterprise offers.

And finally, you Unicorn and Puma "fully-functional" while implying that Phusion Passenger is not. This is not true. There are features in the open source version of Phusion Passenger that Puma and Unicorn does not have. The reverse is also true. It is even true that Unicorn has some features that Puma has and vice versa.

derengel2• 13 years ago

I can understand Ruby and Python, but why nodejs?

FooBarWidget16• 13 years ago

Why not Node.js?

FatalBaboon• 13 years ago

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

perssontm• 13 years ago

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

trustfundbaby3• 13 years ago

I'm pretty sure it supports https

FooBarWidget16• 13 years ago

It supports https through Nginx. HTTPS terminates at Nginx.

WayneDB• 13 years ago

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

Puma, a fast concurrent web server for Ruby

Related Stories