Remember, Scalability (inferiority?) means speed (i.e. c vs. TCL) _and_ throughput. FastCGI might lag in the former relative to AOLServer, but I believe middle-tier scale-out gives it a clear advantage in the latter.
Why would you believe this? The middle-tier technology in AOLserver is almost entirely written in C, after all. That's one of the major advantages of AOLserver's "I'm really an app server not just a web server" design.
Besides which, the FastCGI model gets its fast throughput compared to the mod_perl approach primarily for one reason. Here's a quote from the paper you reference:
Globally initialized objects, for example database connections, are thus persistently maintained.
The FastCGI example connects to PG once, while the mod_perl script connects every time the script is run.
So the benchmark is to a large extent measuring the performance impact of implementing a persistent connection mechanism.
Which AOLserver has built in, of course.
I believe there are persistent db pooling APIs for Perl these days, no? The benchmark would be far more interesting if the FastCGI and mod_perl examples both used one of these modern perl db APIs.
One other area where FastCGI wins over mod_perl is that the script is only compiled once (this is why the db connection is only built once). AOLserver caches the compiled bytecode from libraries and script pages therefore has a similar advantage over mod_perl ...
This does tell me that a fast-performing mod_nsd would have to implement connection pooling (not just the db api) and would need to cache compiled bytecode just like AOLserver does if it would have any chance of performing equivalently. Adding to the complexity of the task.
BTW I'm ignorant of mod_perl so am basing my observations on the paper you've so kindly referenced. If the author's wrong, so am I, I'm just assuming he knows what he's talking about. Based on his comments, though, I see nothing to suggest that the FastCGI approach would yield higher throughput than a properly written AOLserver application.
