|Don't ask to ask, just ask|
Re: FastCGI and mod_perl comparedby mugwumpjism (Hermit)
|on Aug 27, 2001 at 17:23 UTC||Need Help??|
Both FastCGI and mod_perl achieve their speed-up by avoiding the overhead of starting a process for each CGI request.
Yes and no. They both do that, but FastCGI achieves greater speedup by keeping a user-defined number of processes for all requests to be processed by. mod_perl, on the other hand, tries to equip every web server with a fully fledged copy of Perl. Unfortunately this means that if a web server is just serving a flat file, that Perl instance is taking up memory but sitting idle.
Both FastCGI and mod_perl claim benefits beyond speed-up. As a novice I don't understand what many of these features are but according to this chart, mod_perl has more of em.
I had a look at that list. Some of the statements are just plain incorrect, such as "need to reboot httpd when script changes on disk" - for mod_perl this is a cronic problem, in some cases a graceful restart just doesn't work, whereas in the worst case with FastCGI all you have to do is signal a FastCGI script, have it exit, it restarts and you didn't even miss a request. Or, if you prefer, you can have your script automatically check whether or not the critical files have changed and then exit, causing them all to be reloaded. In summary, this is more of a problem in apache and less of a problem with FastCGI, but not according to that chart.
The other "features" I would call mainly "hacks". They're doing all sorts of things with bits of the HTTP request to figure out what to do with it, but why bother when you could do all of that in Perl? Treat the HTTP request as a remote procedure call, which really is what it is. Need authentication? Just write code to check it. Just hand off every request to the FastCGI script to decide what to do with it, so you can specify it in Perl code rather than Apache's arcane and non-intuitive configuration syntax.
And what about memory leaks? mod_perl has no recovery. You have to restart - that is, kill then restart, your web server, causing all current connections to be abruptly broken.
You can attribute this chart to pride (aka Hubris) on Doug MacEachern's part; they put a lot of time and effort into what they did, and their pride makes them blind to the faults in mod_perl. Sometimes it takes an upstart to reject the status quo, who is branded a heretic and thrown out. Currently mod_perl simply does not scale and is a bitch to maintain and code under, but no-one will say that because they don't want to face the rejection; as Carlos Casteneda would say, the first challenge of a man of knowledge is overcoming his fear. Larry wall is wrong in stating that Hubris is a virtue of a programmer. It is good to be self-confident, but to be proud implies that you do not know that something is true and are accepting it to be true based on what someone else said. This is also known as lying to oneself, which increases the level of "consensus with the status quo" in your existance and retricts your ability to see truth.
Let me get this clear to you - FastCGI is a technically superior design. The limitations of mod_perl (ie a hundred copies of Perl being idle) are only solved with mod_perl 2.0, which builds threading into mod_perl; great, but IMO entirely inappropriate for a dynamic web server. When will threading in Perl be stable? I wouldn't trust it until Parrot is considered stable. Because the web server and the perl process are not doing very much communication per request, threading is inappropriate. There is two communications per request; one - the detail of the HTTP request. Two - the response. Why bother with threading for that? Have two processes communicating via sockets or even shared memory and be done with it.
The process for installing FastCGI looks a little scary. The docs begin something like: "...you need a FastCGI-savvy version of Perl..." There doesn't seem to be a debian package for FastCGI...
Any recent version of Perl will do. There is a debian package, too:
It might be easier to run the webserver and CGI programs on separate boxes; I'm not clear on how big a feature [this] actually is.
Depends how big your site is. You'd be surprised how much faster it would be; you'd get effects like the web server code not leaving the CPU's internal code cache, each part of the request being served in one CPU time slice, and so on. Adding an extra tier can make the biggest difference in performance once you reach a certain level. But the mod_perl team wouldn't know that - after all, they can't even do it.
Interestingly, I notice that PHP supports running as a FastCGI process.
If the teacher is not respected, not the material not cared for, then confusion will result, no matter how smart one is. - Tao Te Ching