Puma vs Phusion Passenger

https://github.com/FooBarWidget/passenger/wiki/Puma-vs-Phusion-Passenger

by FooBarWidget • 13 years ago

57 46 13 years ago

nahname2• 13 years ago

I don't understand how people are using multithreaded ruby. Are these people doing something clever that I am not aware of? Or is it just insane amounts of testing?

http://stackoverflow.com/questions/15184338/how-to-know-what...

FooBarWidget13• 13 years ago

Web stuff tends to be embarrassingly parallel: http://en.wikipedia.org/wiki/Embarrassingly_parallel. Which means that it's extremely easy to make a framework that's reentrant: http://en.wikipedia.org/wiki/Reentrancy_(computing). Reentrancy gives you thread-safety by default.

Yeah, Ruby core data structures are not thread-safe. But that doesn't matter. You're not supposed to a lot of any data structures between requests anyway. Of the few that are shared (e.g. the Rails cache object), they are explicitly engineered to be thread-safe.

There's also the story that Ruby cannot use multi-core. That's partially correct: on the MRI implementation, it doesn't matter how many threads you have, only one can be active at a time. However what you can have is multiple processes, each with multiple threads. Each process can use a different core. Furthermore, the JRuby and Rubinius implementations can handle multi-core with multithreading just fine. Both Phusion Passenger and Puma support JRuby and Rubinius.

Maybe I'm just too familiar with Ruby and multithreading, but I don't understand why people have trouble with multithreaded Ruby. In my eyes it's pretty easy. If you have a library that's not thread-safe, then just don't share that library's objects between threads, or ensure that you grab a lock before using that object, and you'll be fine. In my opinion, the situation is not much different in Python, Java or C++.

nahname2• 13 years ago

Being embarrassingly parallel and always being parallel are two separate things. I don't see how the risk of bugs that, generally, show themselves under load would ever make puma worth it. What is the advantage over unicorn? Slightly lower memory usage? My CPU and IO are always pegged way before memory is.

dasil003• 13 years ago

Maybe I'm just too familiar with Ruby and multithreading, but I don't understand why people have trouble with multithreaded Ruby. [...] In my opinion, the situation is not much different in Python, Java or C++.

I think the problem is a mix of language features and culture. Ruby does not have a history good thread-safe practices, and the language has some extremely convenient features which are death for thread-safety (eg. class instance variables). Combine that with prolific meta-programming and a lack of static analysis tools, and it can become very very difficult to be certain that a given application is thread safe. As long as all developers are well-versed and keep thread-safety front and center from the beginning of application developer then I agree it's not hard per se, but in practice that is so rarely the case that if I knew I needed heavy multi-threading for memory efficiency and CPU utilization I might disqualify Ruby on cultural reasons alone (and I say this as a full-time rubyist who knows no language better).

jasdeepsingh3• 13 years ago

Pardon and excuse the self promotion, but just yesterday night I did a small blog post on deploying Rails Apps with Puma. The deployment part is really quite naive and I'm working on part 2 of the post.

http://jasdeep.ca/2013/07/deploying-rails-apps-with-puma-and...

FooBarWidget13• 13 years ago

What was naive about [your deployment section], and what needs updating?

johnbellone• 13 years ago

I think that he meant the deployment section in his post was naive, not yours :).

I appreciate the compare and contrast.

jasdeepsingh3• 13 years ago

Well, I did outlined how simple my approach was in the article I wrote. The approach really works brilliantly for simple projects with one or two servers where you can log on to each machine and just git pull your code and run the migrations etc and be done with the deployment.

For more scalable architectures I prefer putting multiple of these app instances behind a Load Balancer such as Nginx reverse proxy. That is part 2 of my post :)

I'm running Puma in production for a simple project which we have behind a Nginx load balancer.

mtarnovan2• 13 years ago

For Rails 4, you don't need to modify script/rails. Might be good to mention in your article.

jasdeepsingh3• 13 years ago

I haven't had a chance to set this up with a Rails 4 app yet, But you might be right. Thanks for pointing this out. I'll update the article.

FooBarWidget13• 13 years ago

A new section has just been added which compares memory usage.

pkmiec• 13 years ago

I've been using passenger for quite some time and really appreciate its focus on operational tools.

Thanks for the detailed comparison. Good to know how it stacks up against the other options out there.

VeejayRampay• 13 years ago

Just to understand what's going on in this article. The people at Phusion Passenger are comparing Puma and their offer, only to come to the conclusion that if you've got money you should go for their paying offer and if you don't then it's a tie?

Not that they're not to be trusted and can't be unbiased in their judgment, but I'd put more trust in a more independent study,

FooBarWidget13• 13 years ago

That is not the conclusion. As you can see in the comparison, the pros and cons between Phusion Passenger open source and Puma are different. Depending on your needs, either Puma is better, or Phusion Passenger open source is better. That is not the same as a tie.

But we are claiming that the Enterprise version is better than the both of them, with that one exception as documented on the page.

However this should not be interpreted as us abandoning the open source version in favor of the Enterprise version. We are continuously developing the open source version as well. Since the launch of Phusion Passenger Enterprise, the open source version has gained quite some improvements as well.

EDIT: after re-reading the conclusion, I see that it is kind of useless. Other than promoting Enterprise, it didn't say anything substantial. I've reworded the conclusion so that it's hopefully more useful for those who are not interested in Enterprise.

caboteria• 13 years ago

It certainly would have been more useful if it had a disclaimer at the beginning indicating that it was written by a Passenger developer. It's OK to have biases as long as you're up-front about them.

FooBarWidget13• 13 years ago

You mean the URL (github.com/FooBarWidget/passenger) and the fact that the Github page says that the wiki belongs to the "passenger" repository, aren't enough of a disclaimer?

The "License and price" section at the beginning is also worded in such a way that it should be clear that the text came from the Phusion Passenger authors.

jrochkind15• 13 years ago

I posted a showdown of various open source servers that can be run on heroku a few days ago, including puma, which some people interested in this may be interested in:

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

For some reason it didn't get much HN traction. But either it inspired these recent HN posts involving puma, or it's just a coincidence -- either way I'm glad to see puma getting more attention.

I think multi-threaded request dispatch (from either puma or passenger enterprise) are often the best way to maximize throughput in a web server with I/O-bound work, as the Java community has been doing for a while. Any implementation details are just minor tweaks compared to just doing multi-threaded concurrent request dispatch in the first place -- so it's no surprise to see Passenger Enterprise and puma performing similarly.

i agree with the Phusion essay, that Passenger currently has more robust admin/management/supervision features than puma. I hope puma continues to evolve, inspired by passenger

Although these features are not trivial to implement well -- I am very impresed by passenger's feature set, and very robust and reliable performance.

But if you want a free/open-source solution, or a solution that it makes sense to run on heroku -- puma is a (and the only) solid concurrent-request-dispatch solution already.

FooBarWidget13• 13 years ago

Thank you for that benchmark (even though it didn't cover Phusion Passenger Enterprise ;) It looks very thorough.

jrochkind15• 13 years ago

Thanks. I am personally interested in Passenger and Passenger Enterprise -- I do run Passenger (free version) on several self-managed servers, and am happy with it.

There are two reasons I did not include Passenger Enterprise in my benchmarks:

1. As far as I know there is no way to run it on heroku. And I was intentionally benchmarking on heroku.

2. I wasn't going to pay for it just for the purpose of running benchmarks on it.

theuri• 13 years ago

Great analysis - I've been struggling with finding the right server to use for concurrency as I have very long-running requests to a third party API, and this looks like the right choice for us.

wpeterson• 13 years ago

I'm surprised no one mentioned the Rainbows app server, a multi-threaded version of unicorn.

Unless you're running jRuby, you're limited by Ruby's green threads. If you want to saturate all of the cores on your server, you need 1-2 processes per core and then a thread pool within each to keep it well utilized.

I've been running a 4x10 rainbows process/thread setup in production with good results on AWS dual core systems.

randomdata• 13 years ago

you're limited by Ruby's green threads

Ruby (MRI) started using native threads in 1.9, but you are still bound by the GIL.

evanphx5• 13 years ago

Some great points about the tooling, especially the control server. For 2.3, the control server is going to get some much needed needed love that should hopefully address major issues.

A couple of notes: Puma has a dynamic pool but it's common to see people configure the pool as 16:16 in production, meaning it's staticly configured to 16 threads.

Some people have asked about using Puma to manage multiple apps recently. I'm currently consider what that would look like. If it's done, it would likely be a separate gem rather than being wired directly into Puma as it is now.

On the topic of time limiting requests, this is conscience choice. Aborting a thread or process externally is really problematic and I don't personally think it's something that should be done casually. If a user wants to do time limiting, they can easily use a Rack middleware that uses timeout.rb.

The same goes for OobGC. Performing it in a multithreaded env makes little sense because the only out-of-band is when all threads are idle. I have thought of some ways to implement it in puma, but I see OobGC is a kludge. Better to tune your interpreter to handle your garbage load better (something 1.9/2.0/rubinius/jruby can all do).

Thanks for the great comparison! I look forward to future back and forth and we all work to raise the level of technology used in ruby webservers.

cmer3• 13 years ago

Hey Evan,

I keep reading how Puma is meant for be run multi-threaded on JRuby or Rubinius.

Would it be non-sense to run it in "cluster" mode (multi-process) under MRI 2.0? Similar to how we'd run Unicorn, for example. Any benefits doing that versus just running Unicorn?

EDIT: we have plenty of ram so that's not really a concern

evanphx5• 13 years ago

Yeah, you can certainly run puma in the same operational mode as unicorn with clustering. But what I'd suggest is that you do instead is creating 1.5 as many workers has you have cores in your machine and perhaps 8 threads per worker. With that configuration, you'll get much more even performance than unicorn because you won't get as much cpu thrashing from context switches between processes and the threads will allow a high number of concurrent requests to all make progress concurrently.

trustfundbaby2• 13 years ago

For developers running a small vps or any kind of server in which memory is a scarce resource, I highly recommend puma.

I needed about 5-6 passenger processes in my app to service requests in a timely fashion moving to puma essentially cut down the processes I needed to run to 1 ... saving me about 300MB of RAM, but not only did it save me memory, performance was better than with Passenger.

Granted, I miss the ease of just typing

touch tmp/restart

to reboot my app, and I had to set up Apache (then later Nginx) proxying to get it going but it was well worth it.

PS: here is my writeup on how you can get puma up and running with your Apache/Passenger setup in less than an hour to try it out http://www.concept47.com/austin_web_developer_blog/rails/how...

swoker• 13 years ago

You can restart puma pretty easy too with sudo kill -SIGUSR2 `cat tmp/puma/pid`

FooBarWidget13• 13 years ago

If memory is your main concern, then Phusion Passenger Enterprise uses even less memory than Puma. :) We have a discount for cash-strapped startups, students and educational institutions.

trustfundbaby2• 13 years ago

yeah, but puma is free :)

Puma vs Phusion Passenger

Related Stories