On Thu, Dec 15, 2005, Aaron Huslage 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.
Yes, it works the same, if you can get it working. Lots of people can't get fastcgi working under apache. The author of this thread, for instance, is having troubles with that. You're not really passing the traffic through apache anyway. It hits apache, mod_proxy just redirects it. It's not like it's getting processed. You're worrying about a few cycles that take an imperceptible amount of time. > 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. I agree with you about Instiki, but for a while it was the only thing going. Aside from that, just because it's intended to be a single-user or limited-deployment application does not mean that it was intended for use only as a local service. There are people (myself included) who maintain (or used to, in my case) a wiki that is publically readable but only writeable by themselves. In this case it makes a lot of sense to proxy through apache, because it makes it transparent and consistent with the rest of your site. I also wanted to have access to my wiki from anywhere I went, and simply running it locally made that not an option. > 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. You trust your users to write apache configs that won't bring the rest of the server to its knees? That gets *my* sysadmin side scared. Or maybe you don't give your users access to write their own configs. That's another argument for proxying lighttpd (or other services) through apache. Assign your users a port and they can do with it as they please without jeopardizing the integrity of the proxying server. > 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? I think you're thinking too simply. This thread started as a problem-solving exercise, and the scenarios you're talking about all rely on everything working right ;) When everything just works, then yes, use fastcgi through apache (nevermind that its slower than lighttpd, that's another discussion) Proxying is an incredibly lightweight and transparent process, it really doesn't add anything to the debugging process. I've been proxying lighttpd through apache at TextDrive for months and it has never caused me any problems. > 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. I disagree. Proxying (in this case) is akin to port-forwarding on a router. It doesn't really add any complexity and can improve the performance and maintenance of your application. Remember, the primary use case for proxying lighttpd through apache is when you need the features of both on the same machine. For instance, you can't get mod_perl for lighttpd. Lots of people can't get fastcgi working on apache. What happens if you need to run a rails app and a mod_perl app? I'm curious how would you solve that problem? Ben _______________________________________________ PDXRuby mailing list [email protected] IRC: #pdx.rb on irc.freenode.net http://lists.pdxruby.org/mailman/listinfo/pdxruby
