lighttpd makes a proxy comeback
Posted by David July 30, 2006 @ 07:08 PM
As Mongrel continues to bubble to the top of the preferred production stack, we’ve started to evaluate web servers on their proxy rather than their FCGI support. The lighttpd crew has heard this change of priorities loud and clear and the coming version will feature a brand new mod_proxy_core module, which aims to rectify all the troubles of the old mod_proxy.
Jan Kneschke and crew are busy preparing this proxy module for release with lighttpd 1.5.0, but you can already now get your toes wet with the pre-release.
All hail the http pipe!
It’s a series of tubes!
FastCGI was already a forgotten technology when the Rails community led the crusade to revive it a couple of months ago. Funny how the rails community is running away from it now.
You young developers have to try everything for yourself’s. Can’t you for once just have faith in the developers who came before you, created FastCGI, used it and then dumped it?
/me impersonating a web 0.8 C developer
I love the lighty-crew, they serve what the comunity wants.
Ahmad: i agree with you, but the reason why for example mongrel has grown up is because that we all knew from the beginning that fcgi sucks.
Ahmad, also dont forget that we are all early adopters, its a natural thing that we take advantage of the fast growing development process of our environment.
Uh, yeah, Ahmad…what was the alternative to FastCGI back then, eh? Nothing I was aware of. Mad props to Zed for cranking out Mongrel (and scgi before that) and to Jan as well.
Ahmad, proxying wasn’t a viable alternative until we got a Ruby-based web server of Mongrel caliber. So using FCGI was a very natural alternative to follow.
And it served us very well in terms of performance and stability. It “just” had complexity issues. Mongrel is giving us all the benefits (and more) with much less complexity. Win-win!
I still use FCGI and will continue to do so until there another solution.
Tho I love mongrel et al, my Shared host will only allow 1 instance of mongrel running because of the constant memory overhead. On the other hand he doesnt mind me having as many FCGI rails apps as I want.
It would be great if there was a way round this and until there is I think FCGI is here to stay.
What was the alternative to FastCGI before? As I remember the early days of Rails there was none.
In fact, if FastCGI had not been used as the interim solution to prove the viability of Ruby, and Rails by extension, we would have been told to port the whole thing to PHP.
Funny how one man’s abandoned technology is another’s salvation?
The ultimate win would be for mod_ruby to be as good as mod_php and for Ruby support to be as ‘built-in’ without all of these tricks that only work well if you control your own hosting environment (which I do, but few ‘normal users’ can). The day that something like VBulletin or phpBB (name aside) can be developed and distributed as a Rails applcation would be mega.
Thank you all for the explanations. I was making an observation that was no longer relevant, sorry for that.
The only practical alternative to FastCGI was mod_ruby, which I thought was better because it was less complicated. The HTTP approach used in mongrel wasn’t practically available, but it was a viable solution. I mean, mongrel is not ground breaking, tomcat have been using HTTP and proxying since forever.
Anyway, hopefully, with mongrel, this is all behind us now.
Peter Cooper: I agree with you in that PHP is much easier to deploy in a shared environment.
But most of the Rails community is now focused on hosted web applications, so this is irrelevant to them. They might not be inclined to tackle it. Thankfully, Rails is open source so web software companies and web hosting companies are free to find a solution to this problem.
So is there a middle ground here? Some method of adaptive spawning of mongrel processes?
Peter Cooper: I totally agree. It seems to me that deployment is one of the most complicated elements of Rails.
@Peter: I heard that Shugo Maeda is working on updating mod_ruby to work better with Rails, but it’s not ready quite yet.
peter that would be great ! any idea whats holding mod_ruby back ?
jonah, I thought from my understanding is mongrel wouldn’t use more memory then FCGI anyways. Since 1 mongel is the same as 1 FCGI instance. They both load up the rails framework and your app into memory. The only difference is mongel uses HTTP as its communication instead of FastCGI which gives your more options.
So running 5 FCGI’s would be equivelent as running 5 Mongrel’s.
So sounds like your hosting isn’t fully informed about it and thinks Mongrel is a full featured Web Server like Apache and forks or threads out requests instead of being 1 per app.
It would greatly help to have Rails thread-safe so that if the day ever came that mod_ruby was a viable option, that use it.
“deployment is one of the most complicated elements of Rails”
Hardly IMO. See Capistrano, or just straight SVN. All somebody would need to do is install Rails, then export from SVN (or extract a SVN export).
A (much) better mod_ruby/rails would be nice (especially for Lighty).
Joe – Am I mistaken or does cap not set up your web server for you ;) I think thats what’s being refereed to as complicated deployment. Getting your web server up and running with apache/lighttpd/lightspeed/ fcgi/fastcgi/mod_ruby/mod_proxy/ mongel/mongrel_cluster or whatever you decide.
Schultz, can u run multiple apps from 1 mongrel instance ? u can with FCGI
Joe, ... sure if u have capistrano and svn etc and u know what u are doing its pretty straight foward, but it’s hardly as easy as installing a PHP app – i.e. copy and paste !
Getting up and running with Lighty and Mongrel is easy. Apache+PHP, much less so, if you want to tweak the installation.
I am thinking that from the point of view of a newbie dev, it’s hard.
Theres so many cheap hosts out there with decent Apache + PHP support, where I would be able to simply upload, chmod a couple of files and I’m away.
Ones with Lighty + Mongrel support ….. hmmm
yo just wanna say i’ve been using litespeed (http://www.litespeedtech.com) (no i don’t work for them) with great joy on my personal site (http://www.tourfilter.com) – it has a native, configurationless rails interface called LSAPI that makes it as simple to use rails with it as it is to use php with apache … it’s not open source, but it is free, and it … just works. It’s configuration-compatible with Apache and also a lot faster than Apache. Mongrel can be a headache to configure with apache because you have to have a dedicated balancer between the two.
From a security standpoint, I will never use mod_ruby, or even a mod_fcgi that runs as the same user as the web server. The best part of a proxying routine is the ability to have the rails process run as a different user than the web server. This keeps multiple users or multiple apps from being able to read critical files such as the database password file.
Today I did an indepth performance benchmark of Lighttp/Mongrel/Rails vs. Lighttp/Fastcgi/Rails on a dual processor server using the latest pre-release Lighty code. Bottom line, after tuning to achieve saturation, throughput of three Fastcgi instances was 273 requests/sec. and a pack of four Mongrels clocked 192.
The HTTP proxy approach adds flexibility (and is what I’d prefer), but, for now, you pay a price in performance. Of course, for many websites, the performance difference may not matter.