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