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

Puma vs Phusion Passenger

github.com

Post reply on HN
Print view View original

21–30 of 47 posts

Re: Puma vs Phusion Passenger

#21

Post by jrochkind1 »

FooBarWidget wrote: post #8
nahname wrote: post #7

Earlier quoted context omitted.

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.

The advantages depends on the workload. For a lot of applications, i.e. applications with CPU-bound, fast-running requests, multi-process behind a buffering web server (Phusion Passenger default style, Unicorn style) is fine and works great. Don't move away from that. When it comes to this kind of workload, both Phusion Passenger (open source and Enterprise alike) and Unicorn work better than Puma. While Puma can be…

I think that MOST web apps perform enough I/O to see huge advantages from concurrent request dispatch. Like, say, calls to the database. Most web apps do a significant amount of I/O, they are not strictly web bound.

If the request-response loop spends a non-trivial amount of time waiting on I/O -- and most do -- then concurrent request dispatch has huge advantages. I tried to investigate/show that in these benchmarks: https://github.com/jrochkind/fake_work_app/blob/master/READM...

(And writing a ruby app to actually work right with evented/reactor-style request dispatch turns out to be way worse than multi-threading, in actual practice. http://www.slideshare.net/KyleDrake/hybrid-concurrency-patte... )

(Your reference to 'blocking I/O' is confusing, I think -- that phrase means different and sometimes opposite things to different people/contexts. But it's not even neccesary to get into it for this discussion, you just mean 'I/O' at all, I think.)

Re: Puma vs Phusion Passenger

#22

Post by FooBarWidget »

jrochkind1 wrote: post #21
FooBarWidget wrote: post #8

Earlier quoted context omitted.

The advantages depends on the workload. For a lot of applications, i.e. applications with CPU-bound, fast-running requests, multi-process behind a buffering web server (Phusion Passenger default style, Unicorn style) is fine and works great. Don't move away from that. When it comes to this kind of workload, both Phusion Passenger (open source and Enterprise alike) and Unicorn work better than Puma. While Puma can be…

I think that MOST web apps perform enough I/O to see huge advantages from concurrent request dispatch. Like, say, calls to the database. Most web apps do a significant amount of I/O, they are not strictly web bound. If the request-response loop spends a non-trivial amount of time waiting on I/O -- and most do -- then concurrent request dispatch has huge advantages. I tried to investigate/show that in these benchmarks…

Well, local I/O, and sometimes even LAN I/O, tend to behave close to non-blocking. The latency is very small, unless your database is under heavy load, but then you have other problems anyway.

With blocking I/O I mean I/O calls which put the process to sleep for a while. This is in contrast to I/O calls which succeed immediately.

Re: Puma vs Phusion Passenger

#23

Post by wpeterson »

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.

Re: Puma vs Phusion Passenger

#24

Post by rschmitty »

FooBarWidget wrote: post #17
caboteria wrote: post #16

Earlier quoted context omitted.

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.

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.

To be fair, I only associated the name FooBarWidget with passenger after figuring out you are the author on the project.

Any reason why you do not keep it with the company repo https://github.com/phusion ?

Re: Puma vs Phusion Passenger

#25

Post by randomdata »

wpeterson wrote: post #23

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 syst…

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.

Re: Puma vs Phusion Passenger

#26

Post by FooBarWidget »

rschmitty wrote: post #24
FooBarWidget wrote: post #17

Earlier quoted context omitted.

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.

To be fair, I only associated the name FooBarWidget with passenger after figuring out you are the author on the project. Any reason why you do not keep it with the company repo https://github.com/phusion ?

Historical. The Phusion Passenger repository started in 2008, when Gitub did not yet support teams. We never moved it because there are so many links to FooBarWidget/passenger.

Re: Puma vs Phusion Passenger

#27

Post by evanphx »

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.

Re: Puma vs Phusion Passenger

#28

Post by mtarnovan »

FooBarWidget wrote: post #26
rschmitty wrote: post #24

Earlier quoted context omitted.

To be fair, I only associated the name FooBarWidget with passenger after figuring out you are the author on the project. Any reason why you do not keep it with the company repo https://github.com/phusion ?

Historical. The Phusion Passenger repository started in 2008, when Gitub did not yet support teams. We never moved it because there are so many links to FooBarWidget/passenger.

I think Github will automatically set redirects for you if you move a repository around.

Re: Puma vs Phusion Passenger

#29

Post by mtarnovan »

jasdeepsingh wrote: post #3

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

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

Re: Puma vs Phusion Passenger

#30

Post by FooBarWidget »

mtarnovan wrote: post #28
FooBarWidget wrote: post #26

Earlier quoted context omitted.

Historical. The Phusion Passenger repository started in 2008, when Gitub did not yet support teams. We never moved it because there are so many links to FooBarWidget/passenger.

I think Github will automatically set redirects for you if you move a repository around.

Really? A few months ago when I tried to move a repo Github showed a big warning, explicitly telling me that they do not setup redirects. Maybe that has changed now.
Post reply on HN