I proxy traffic through Apache 2.0 (which I use for svn) to lighttpd because FCGI is unstable under Apache 2.0. It's hardly complex at all, in my opinion. At the "microscopic" level, all that's happening is a mod_rewrite to the URL the user requested, and Apache is quite efficient at doing this.
However, having done some work at Robot Coop (they push around 1 million page views a day), I prefer Apache 1.3 and FCGI for high load situations. I can't say I've seen anything with lighttpd that scares me, but I tend to trust that Apache isn't going to get weird on me in high load. I still need to worry about FCGI, but I'd have the same concerns with lighttpd. As far as installing Rails goes - I notice, Preston, that you mention that you're running RHEL. I had an absolute hell of time getting Rails to work in any configuration under RHEL. I eventually had to abandon any idea of using RPM installations and give in to compiling Apache 1.3 and FCGI. Since my first install on RHEL, I've been able to install Rails on RHEL with Apache 2.0 proxied to lighttpd as well, and the only way to do it is to compile it. I'm not always comfortable with that option myself, as I'm not a linux guru, or even poweruser, by any means, but it was the solution to a lot of headaches. On 12/15/05, Aaron Huslage <[EMAIL PROTECTED]> wrote: > FastCGI works the same under either web server, so I see no reason to > pass FCGI traffic through Apache, then through Lighttpd, then to FCGI > and back again. It's added complexity than is unnecessary, IMHO. > > Webrick is another story...Instiki is broken I think, or rather the > use of it is wrong. Instiki wasn't really meant for anything more than > a local service, so Webrick is more than sufficient. If you want a > solution to that, try i2 or some other wiki engine. > > In a shared environment, why not just give a user an Apache config of > their own that is included in the main site's config? That's what I've > always done. > > I see ProxyPass as useful if you are trying to centralize access to > many services on several (or one) boxes, and I suppose a case could be > made for using it at PA. It just seems to me that it's quite a lot of > hoops to jump through from a debugging perspective. Why not just bind > apache to one IP and Light to another in this case, for instance? > > It seems like you're killing the beautiful simplicity of a Rails app > by adding complexity on the front-end. This is a bit Java-esque. In > this case, FCGI is the App Tier, with 2 layers of web-tier on top. > >From a sysadmin POV, that's a bit of a problem and something that can > bite you in the ass fairly easily. > > On 12/15/05, Ben Bleything <[EMAIL PROTECTED]> wrote: > > On Thu, Dec 15, 2005, Aaron Huslage wrote: > > > Is this a real world example? Is there a reason that someone would > > > want to or need to do this? Lighthhpd + Apache? As a sysadmin, I worry > > > about stuff like this. > > > > Why? This is a very common deployment environment for rails apps. The > > common case is when you need existing apache functionality (mod_perl, > > mod_php, etc) and don't want to or can't get fastcgi working with > > apache. > > > > It's also useful for Instiki (and presumably other apps) that only run > > under webrick. > > > > Really, what is there to worry about? > > > > Ben > > _______________________________________________ > > PDXRuby mailing list > > [email protected] > > IRC: #pdx.rb on irc.freenode.net > > http://lists.pdxruby.org/mailman/listinfo/pdxruby > > > > > -- > Aaron Huslage > www.inveneo.org > Cell: 503.860.1634 > Office: 415.901.1969 x1245 > _______________________________________________ > PDXRuby mailing list > [email protected] > IRC: #pdx.rb on irc.freenode.net > http://lists.pdxruby.org/mailman/listinfo/pdxruby > _______________________________________________ PDXRuby mailing list [email protected] IRC: #pdx.rb on irc.freenode.net http://lists.pdxruby.org/mailman/listinfo/pdxruby
