On Sun, 2006-03-12 at 18:30 +0100, Michael Metz wrote:
> Craig White wrote:
> > On Sun, 2006-03-12 at 17:33 +0100, Michael Metz wrote:
> >> Hi all,
> >>
> >> I've read a bit about fastcgi, and wondered if it might be an
> >> interesting solution for e.g. running php in a user-switched environment
> >> or running ruby-on-rails etc.
> >>
> >> But I wonder why nobody (searched on Google) seems to use CentOS with
> >> mod_fastcgi for Apache 2.x.
> >>
> >> And I also wonder why people actually using Apache 2.x and ruby-on-rails
> >> with CentOS did run a lighthttpd-fastcgi inbetween and reverse-proxying
> >> requests from Apache to lighthttpd to actually forward them to RoR
> >> running as fastcgi.
> >>
> >> Could sombody please give me a hint?
> > ----
> > my original efforts at setting up ruby on Fedora, I used lighttpd
> > w/fastcgi and it was fairly easy to set up.
> >
> > my current 'production' system is using CentOS 4 & apache w/ fastcgi and
> > it was a little more effort to get working but it works and is fine. I
> > really don't want to bother with also running lighthttpd at this point
> > (and then using apache to proxy the rails stuff to lighttpd at this
> > point, primarily because it's not an issue and I'm lazy and I believe in
> > keep it simple).
>
> I really appreciate to hear that. So at least it actually works without
> lighthttpd inbetween :-)
----
actually, I think you have it the other way around...apache would do the
proxy and be the in between in the scenario I just pointed out. I'm not
sure if lightty does proxy
Anyway, those in the know (and I am not one of those), say that lightty
is much faster at delivering the dynamic content via fastcgi than is
apache - even apache 2.0 with fastcgi
To answer your questions though...
Rails will work on apache using standard cgi...it will be slow
Rails will work on apache using fastcgi, you have to add it yourself -
see below for link
Rails (at this moment in time) apparently is fastest using lighttpd with
fastcgi and the only reasons that you might have to deal with apache
and/or proxy is because you can't shut off apache on that system for
some reason or another in which case, you set up proxies in apache to
handle each RAILS_ROOT you intend to serve with some other lighter
weight web server such as lightty or mongrel or even webrick and since
apache is already using port 80, those other lighter weight web servers
must necessarily be on different ports.
----
>
> > I think the reason that people do things like that is because they need
> > to run apache on the system for some stuff which will tie up ports
> > 80/443 and then lightty can't use them so it has to use other ports and
> > you simply proxy the paths to the lightty application and their specific
> > ports. This allows the speed of lightty and the user/dns simplicity of
> > url's without using the specific port assignments which would
> > necessarily have to be used when running lightty on a system already
> > runing apache.
>
> I agree that it might make some sense to replace apache with lighthttpd
> in some setups. But to my understanding when you proxy a request through
> that also ties up an apache-process. And you might run into problems
> because the application running in lighthttpd might have problems
> getting the original requester-IP. Or am I wrong? So basically I still
> see no point in using lighthttpd there inbetween - only that I found
> ready-to-use lighthttpd-fastcgi-packages (build for CentOS), whereas I
> didn't find httpd-mod_fastcgi-RPMs.
----
http://wiki.rubyonrails.org/rails/pages/Fast+CGI+with+Apache2+and+RHEL+4
Craig
