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:
> > 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?