> Well for one thing, many sites are a mixture of static assets and
> dynamic content. It's much more efficient to serve the static assets
> from a webserver tuned for serving this sort of content, rather than
> serving your entire site from a ruby server.
Right, that's the reason most of the older setups called for something like
Apache or nginx, proxied to something like mongrel.
I wanted to amplify with use cases that run more than one app on the same
server. My experience is that getting two *Rails* apps to play nicely in
the same environment is a pain.
Huh. I don't know that I'd call it "easy", but I was able to solve this by
running those apps as separate user accounts, separate databases and MySQL
passwords, etc. Once I had a task set up for it, the biggest irritation was
managing ports. With Unix sockets and a master/slave setup like Unicorn, that
goes away.
With Passenger I can run Rails alongside PHP, and serve static
content far more efficiently. (nginx is on my saw-sharpening list...)
I definitely ran PHP when I was doing the above. Remember, with the
traditional setup, each mongrel is a separate webserver to proxy to. It's not
hard to proxy to another server running PHP, if you have to.
But basically what I'm hearing is that I'm right -- ease of setup/deployment
is _the_ win for Passenger.
One possible point against passenger: How easy is it to run each individual
Rails app as a separate user?
···
On Wednesday 25 November 2009 05:21:52 pm Judson Lester wrote:
On Wed, Nov 25, 2009 at 2:17 PM, Brian Candler <b.candler@pobox.com> wrote:
Marnen Laibow-Koser wrote:
And running multiple Rails apps with one Passenger installation is
likwise a breeze.
- although there's some possibility for interaction between them. In
particular, PassengerUseGlobalQueue gives one global queue across all
apps, rather than one queue per application. Also,
PassengerMaxInstancesPerApp can only be set globally rather than per
app.
At least it was like that last time I enquired, but the current
documentation suggests this is still the case.
···
--
Posted via http://www.ruby-forum.com/\.
David Masover wrote:
[...]
One possible point against passenger: How easy is it to run each
individual
Rails app as a separate user?
Trivial. IIRC, each Passenger app runs as whichever user owns (I think)
it's environment.rb file.
Best,
···
--
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
--
Posted via http://www.ruby-forum.com/\.
David Masover wrote:
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
···
--
Posted via http://www.ruby-forum.com/\.
Brian Candler wrote:
Marnen Laibow-Koser wrote:
And running multiple Rails apps with one Passenger installation is
likwise a breeze.
- although there's some possibility for interaction between them. In
particular, PassengerUseGlobalQueue gives one global queue across all
apps, rather than one queue per application. Also,
PassengerMaxInstancesPerApp can only be set globally rather than per
app.
At least it was like that last time I enquired, but the current
documentation suggests this is still the case.
I think it may not be, but don't quote me. 
Best,
···
--
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
--
Posted via http://www.ruby-forum.com/\.
David Masover wrote:
> 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
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.
···
On Friday 27 November 2009 02:48:50 am Brian Candler wrote:
David Masover wrote:
*and* ongoing management and tuning - it handles dynamic pools of
processes for you
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.
···
--
Posted via http://www.ruby-forum.com/\.
David Masover wrote:
>> *and* ongoing management and tuning - it handles dynamic pools of
>> processes for you
>
> 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.
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.
···
On Friday 27 November 2009 04:40:55 am Brian Candler wrote: