Ruby a good choice for CGI?

[Brian Candler]

But basically what I'm hearing is that I'm right -- ease of
setup/deployment
is _the_ win for Passenger.

*and* ongoing management and tuning - it handles dynamic pools of
processes for you

*and* RAM usage - when combined with REE, the forking of your app means
much of the ruby object space is shared, so more performance for the
same $$

*and* it has excellent documentation

One possible point against passenger: How easy is it to run each
individual
Rails app as a separate user?

It does this by default.
http://www.modrails.com/documentation/Users guide
Apache.html#user_switching

 

[David Masover]

*and* ongoing management and tuning - it handles dynamic pools of
processes for you

So does Unicorn, or maybe I'm not understanding.

*and* RAM usage - when combined with REE, the forking of your app means
much of the ruby object space is shared, so more performance for the
same $$

Unicorn does this, too.

*and* it has excellent documentation

That's a win, I guess.

I don't mean to start a big debate here, nor am I wanting to just shout "I
heart Unicorn", I'm actually trying to understand pros and cons. I'm still
seeing "ease of use" in some form as the big win for Passenger.

 

[Brian Candler]

So does Unicorn, or maybe I'm not understanding.

http://unicorn.bogomips.org/

From reading this, and the FAQ/Philosophy, it sounds like you configure
it with a *static* sized pool. They advise you to spit out the request
as quickly as possible into a buffering reverse proxy, so you can get
onto handling the next request - then you scale your app to the
available CPU resources, rather than to the number of concurrent
clients.

That's a reasonable approach for many apps, whatever server you deploy
them under. OTOH that won't work for apps which return large or infinite
streams.

Also, as far as I can tell, to use Unicorn properly requires you to use
nginx (at least, I don't know if apache can proxy to a unix domain
socket, and the documentation doesn't seem to mention apache)

On the plus side: you do get very fine-grained control of the
deployment.

Anyway, it's always good to have alternatives. Projects come and
projects go, and it's comforting to know there are things to migrate to.

 

[David Masover]

http://unicorn.bogomips.org/

From reading this, and the FAQ/Philosophy, it sounds like you configure
it with a *static* sized pool.

Ah. Thanks for the clarification.

That's a reasonable approach for many apps, whatever server you deploy
them under. OTOH that won't work for apps which return large or infinite
streams.

Yes, I think that's what Rainbows is for. But I haven't looked into that in
much depth. From the readme: "We aim to support as many concurrency models as
we can because they all suck; differently."

Also, as far as I can tell, to use Unicorn properly requires you to use
nginx (at least, I don't know if apache can proxy to a unix domain
socket, and the documentation doesn't seem to mention apache)

It can also listen via TCP.

On the plus side: you do get very fine-grained control of the
deployment.

Yes, that was the big win for me.