Re: FastCGI and mod_perl compared

[echo]

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.

No one in its right mind serves flat files with a mod_perl server. Any decent production server will use a front-end reverse proxy to serve static resources, and hand off requests for dynamic documents to the mod_perl back end. For example I have such a server with 300 front-end processes and only 12 back end mod_perl processes.

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.

You can certainly write all that code in Perl with mod_perl, that's precisely the point of having hooks into all request phases. Apache encourages modular code, so that although you can do your authentication, url rewriting, logging, etc, in your content handler, just as you would with a regular CGI, it is advisable to use the proper request phase hooks instead. This provides for more reusability. Want to authenticate against a SQL database? Just plug in Apache::AuthenDBI and you're done. I'm not sure what you're talking about when you say that this could all be done in Perl instead: mod_perl precisely lets you do all that in Perl, it just follows the Apache request model so that you don't mix authentication, content delivery, etc, in one script. One of the major benefits of this is that you can use a number of CPAN modules that deal with common tasks.

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.

This is at best an unsubstantiated opinion. There are many large sites that use mod_perl. Once you learn to use strict, there's not much more to writing mod_perl code than there is to write regular CGI code.

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.

Obviously you haven't done much work with mod_perl. A request goes through 11 phases during its lifetime, each of which can be handled by Perl code. That code has access to the full Apache API, which goes way beyond just accessing the handful of environment variables available under CGI. As for threading (not available yet, will be under 2.0)--many think that superior performance can be expected of a threaded server, but the Apache developers still provide the 1.x prefork model in 2.0. mod_perl 2.0 supports threading because Apache 2.0 supports it, you don't have to use it if you don't like it. However one might like the fact that multiple threads will share the Perl interpreter (through 5.6.x cloned interpreters) which will greatly reduce memory requirements). A threaded server's primary benefit isn't for communication between threads, it's about increased performance and reduced resource consumption compared to the multiple process model. At any rate, suggesting sockets or shared memory as a way to improve performance is almost laughable, as these techniques don't scale very well.

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.

I am not sure what you're saying here--mod_perl does not impose a web server architecture for you. It's just a technique to handle dynamic requests. Any moderately busy site will use a multi-tier architecture, whether you're using mod_cgi, mod_perl or PHP. Apples and oranges.

As to your comments on Doug MacEachern's supposed pride, I don't know where you got that from. Doug is one of the shyest and yet most helpful guys around. He does believe that his product is good, but I've never seen him make any bold statements about its superiority over other products that have the same goals. It's just a tool, choose the tool most suited for the job, and the one you feel most comfortable with.

If you wish to compare technologies, you'd do a service to your readers if you acquire similar knowledge about each technology you're evaluating, and restrict your comments to the technology themselves. This way you won't have to resort to inflamatory comments about the authors.