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

41–47 of 47 posts

Re: Puma vs Phusion Passenger

#41

Post by cmer »

evanphx wrote: post #39
cmer wrote: post #34

Earlier quoted context omitted.

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

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

8 threads per worker on MRI? Isn't that a recipe for disaster? Or maybe I'm missing something?

Re: Puma vs Phusion Passenger

#42

Post by evanphx »

cmer wrote: post #41
evanphx wrote: post #39

Earlier quoted context omitted.

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

8 threads per worker on MRI? Isn't that a recipe for disaster? Or maybe I'm missing something?

Why would that be recipe for disaster? What do you think would happen?

Re: Puma vs Phusion Passenger

#44

Post by trustfundbaby »

FooBarWidget wrote: post #37
trustfundbaby wrote: post #33

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

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.

yeah, but puma is free :)

Re: Puma vs Phusion Passenger

#46

Post by jrochkind1 »

FooBarWidget wrote: post #22
jrochkind1 wrote: post #21

Earlier quoted context omitted.

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.

In most of the web apps I've written, the majority of the request-response latency is waiting on the database, rather than cpu. I _think_ this is not uncommon?

In other contexts, people talk about "non-blocking IO" and "blocking IO" to mean, well, 'blocking IO' is where the process or thread is _not_ put to sleep, it's not being switched out _even though_ it's waiting on IO. For instance, most ruby database drivers used to be broken in this way with respect to multi-threading, but were fixed to be "non-blocking IO", so threads would actually be unscheduled (even in MRI) when waiting on IO.

For examples of this use of "blocking IO" vs "non-blocking IO" see http://en.wikipedia.org/wiki/Asynchronous_I/O (Ha, look what wikipedia URL did to "I/O").

That usage is pretty common, so I think your different use of 'blocking IO' is confusing.

Re: Puma vs Phusion Passenger

#47

Post by jasdeepsingh »

mtarnovan wrote: post #29
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.

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.
Post reply on HN