Apache gets serious about FastCGI
Posted by David December 29, 2005 @ 05:30 AM
Brian McCallister reports that the Apache team has decided to revive mod_fcgi as mod_proxy_fcgi with intentions of proper support for external FCGIs and a place in the core Apache distribution.
This is fantastic news! Paul Querna and Garrett Rooney deserves much praise for embarking on this important quest to restore our faith in Apache as a worthy web server for applications. Not only will this mean that FCGI is no longer a bastard child on Apache 2.x, but also that it’ll have active maintenance and people to turn to if things are sour.
Speaking of sour. Please do forward all your grapes to Brian McCallister or the FastCGI Developers list. Any trouble you’ve had in the past with FCGI and Apache or things you’d like to see happen.
Viva la Apache!
The link to Brian’s email address is wrong, it should have a mailto: in front of it.
Yay! It’s good to see this activity taking place. I’ve updated my Real Lessons for Rails Deployment peice accordingly.
Hopefully work will progress quickly and we’ll have a real solution for 2.2 either built-in or available as an official mod_fastcgi distro.
Will this increase Ruby’s performance? Meaning increase responsiveness (response time) and most importantly, increase the number of concurrent users Ruby on handle (which I believe for a print “hello world” is approx. 3 users/sec)?
If so, by how much (estimate)?
It happened because there’s a bug in the AJAX posting in Firefox. Its a pretty nasty bug that needs to be fixed ASAP.
I don’t think there’s a way to tell you what the exact speed increases would be with Apache support of FCGI (and it would depend on what kind of current Apache configuration you would be comparing it to), but it would definetly put it more on par with lighttpd. This is certainly excellent news because Apache is definetly one of the best and certainly the most prominent web server out there. Its good to know we’ll soon be able to use FCGI processing.
I’ll be sure to send my grapes Brian McAllister. Does he prefer red or white grapes? :-) Sorry couldn’t resist.
Anyone know where to go for some help compiling the ruby-fcgi bindings? There’s no apparent mailing list or website.
Excellent news!
Although lately I’ve been feeling that Apache + FastCGIExternalServer + Rails isn’t that bad of a setup as it is :)
One of the best? Is that a joke? It is the best webserver you can get in the world.
If you need help getting your ruby on, you might want to consider RecentChangesCamp which is free and has sponsored hotel rooms as well. RecentChangesCamp is a BarCamp un-conference where you’ll actually get to interact with each other and the luminaries rather than watching a bunch of present-from-the-pulpit style presentations. Portland has one of the largest most active Ruby user groups in the world, and we are going to have some great hackfests at RecentChangesCamp!
It’s going to rock … and it will be even better if you invite the people you ‘d like to know so that you can meet face to face and hack on rails together.
Go to RecentChangesCamp.org, click edit, add your name to the list and then start sending out invites! It’s the Conference2.0 way and seems like a natural fit for those who’ve tasted the rubylicious!
Is this really a reality. I only ask because after reading the comments on the article
http://kasparov.skife.org/blog/src/apache_22_fcgi.html
It doesn’t sound too promising.
h
It is a reality, just not close to done yet =)
One of the best? Is that a joke? It is the best webserver you can get in the world.
Are you serious? Have you ever run a site that gets more than 5 req/s?
One of the best? Is that a joke? It is the best webserver you can get in the world.
Jeez, some people are so damn sensitive about their technologies. Apache is the best webserver for most people and for most applications most of the time, but it isn’t always. For instance, RoR applications. It has been a nightmare to setup with RoR applications. Of course that’s not really the fault of Apache developers, but nonetheless, lighttpd has been relatively easy to setup and has been freakin awesome as a webserver for my needs.
Now take a deep breath and calm down.
And what about SCGI? It does about the same performance, but it already runs much better on Apache and it’s easier to install!
Offtopic but still interesting for RoR:
I wonder who would win this contest/race if it were allowed to use RoR as a “toolset” :) : http://wiki.javapolis.com/confluence/display/JP05/RAD+Race
From this page: http://radrace.org/en/JPed_2005/JPwinners_2005.html
“None of the teams was able to finish..” :).
What about mod_ruby? It proved to be the best solution in PHP, Python and Perl.
Why do we need to revive FastCGI? FastCGI has too many features for our needs and I see it as a typical example of specs that are too optimistic.
What about mod_ruby? It proved to be the best solution in PHP, Python and Perl.
Why do we need to revive FastCGI? FastCGI has too many features for our needs and I see it as a typical example of specs that are too optimistic.
What about mod_ruby? It proved to be the best solution in PHP, Python and Perl.
Why do we need to revive FastCGI? FastCGI has too many features for our needs and I see it as a typical example of specs that are too optimistic.
What about mod_ruby? It proved to be the best solution in PHP, Python and Perl.
Why do we need to revive FastCGI? FastCGI has too many features for our needs and I see it as a typical example of specs that are too optimistic.
What about mod_ruby? It proved to be the best solution in PHP, Python and Perl.
Why do we need to revive FastCGI? FastCGI has too many features for our needs and I see it as a typical example of specs that are too optimistic.
Actually, Ahmad, mod_(php|perl|python|ruby) has proven to often not be the best solution in practice. Embedding your interpreters in the httpd process often ends up just handcuffing you later when it comes time to do a site (perhaps one of many) upgrade, and sucks away precious memory in each Apache process making it harder to scale higher traffic sites up in volume. Per-user runners are also incredibly convenient for mapping sites into OS sandboxes (via ulimit, RBAC, SELinux, whatever).
I’m with David Morton though, and think that at this point SCGI is the better way to go if your backend doesn’t do smart proxy rewriting. FastCGI is quickly becoming irrelevant for the Python and Ruby frameworks that matter to me. I really think Zope has it right in this regard making it easy, quick, and reliable to proxy rewrite requests from Apache into the Zope appserver (and VirtualHostMonster) via mod_proxy.
I agree with you, Mark, on that FastCGI is too complicated for most peoples purposes. And I also agree that SCGI (from my limited exposure to it), is much better.
What I like about mod_* is that they are the easiest to use. Once the server is up, they are all up and running. You can use Apache’s configurations that you are used to like mod_rewrite, virtual hosting, .. etc.
I think that the upgrade problem can be solved using shared libraries and some kind of package management (I specially like Debian’s apt). I also think that the memory problem can be solved using some smart coding. If it is possible to have two seperate processes communicating over TCP/IP take a certain amount of memory while doing something, it should definitly be possible to have a single process do the same thing with the same amount of memory (if not less).
Ahmad, package management isn’t going to solve the problem of getting two different versions of the Ruby interpreter into memory as Apache modules at the same time. Smart coding isn’t going to magically eliminate the fact that each Apache process (4 per connection on average) carries the interpreter (via a shared object, no less!) and since requests are round-robin’ed across available processes each process will end up tickling all the memory pages required to run your code. Which means each process, even if it’s just sending out a little .css file, is going to be taking up dozens of megabytes of memory.
I’ll try to update the FastCGI post I made (trackbacked below) to include more details on how it’s difficult to scale Apache with the mod_* approach. I encourage you to take the conversation there if you want to discuss further. Thx!
Aha. There are many things I didn’t know about. I’ll read your post and if I have any questions, I’ll ask them there. Thanks a lot Mark.
@Ahmad: Well, FastCGI is not just for Ruby. It’s a very general and clean design. I welcome its ressurection :-)