I found these informative links in my research into high performance web application platform and thought you might find them useful as well.
To start off, A Comparison of Portable Dynamic Web Content Technologies for the Apache Server provides good overview of the choices. I think its numbers for Java Servlets are somewhat off, but not enough to affect the conclusions. FastCGI + Perl was the clear winner in the paper, followed by mod_perl. Only surprise was the poor performance of PHP. mod_python was not test unfortunately.
If you are curious about the performance differences between Apache 1.3x and Apache 2.0x, Open-Source Web Servers: Performance on a Carrier-Class… provides some benchmarks. This paper might be outdated though. If you know of current state of the performance differences, let me know. In short, the paper shows that there are only marginal differences except Apache 1.3x scalability was not consistent in one of the tests.
AMK's Diary blog post Web server performance clued me to SCGI which was designed to be easier to implement than FastCGI. When Linux Weekly News switched from mod_python to SCGI, performance improved significantly. The post goes on to suggest why this might be.
Understanding FastCGI Application Performance provides more thorough explanation of why FastCGI (and SCGI) performances are so good. After reading the paper, I set out to compare FastCGI and SCGI and found this archived message by Michael Watkins. If the numbers are right, SCGI is much faster than FastCGI.
SCGI is released by MEMS Exchange, an apparently non-profit organization serving chip fabrication centers. MEMS Exchange also makes available a number of useful Python software for free, most interesting of which (at least to me) is Quixote. Quixote is a Python web application framework that can support many architectures (see Quixote whitepaper).

a SCGI-based architecture
I would have liked to see how SCGI compared to mod_perl, but found only an informal comparison of FastCGI and mod_perl. I would have also liked to see comparison of mod_perl-based Perl web applications and SCGI+Quixote based Python web applications, but found nothing in this run.
By chance, I did run across Apache Hello World Benchmarks, a very informative benchmark report. It even compares popular Perl web application frameworks like Mason and HTML::ASP. The numbers were enough to made me lose interest in Mason. Phew. I am saving a local copy of the benchmark because I know I'll be coming back to it often.
So, I'll be looking into SCGI and Quixote in the near future. Did you know that during my wild younger days, my friends called me Don Quixote?
Update #1:
SCGI picture has dimmed a bit. Only SCGI server implementation I could find was MEMS Exchange's which is written in Python. This spells trouble for non-Python. Also Apache2 version of mod_scgi, Apache module implementing SCGI client code, is not available. Some efforts were made but they were abandoned.
I can't imagine mod_scgi being difficult to write, so it must be the lack of interest. But lack of interest despite apparent superiority over other solutions doesn't make sense to me. Geeks vote with their feet and lack of footsteps around SCGI leaves it looking less attractive to me. Maybe it's Python being supposedly slower than Perl and its GIL (Global Interpreter Lock) curse. In comparison, Perl looks awefully good in terms of geeks voting with their feet.
Speaking of popularity, mod_perl easily beats FastCGI despite the performance advantage FastCGI has. Some of the reasons cited are: better support, bigger developer community, and tighter integration.
Herd behavior enhances survivability
Update #2:
Neil Schemenauer, author of mod_scgi, wrote to say mod_scgi for Apache2 exists but shouldn't be used for serious use until more testing is done. He mentioned that there is nothing Python-specific about SCGI and he would be happy to provide support to people writing non-Python SCGI bindings. He also pointed to mod_list as an alternative to mod_scgi but I couldn't locate it via Google.
Update #3:
Neil was referring to mod_lisp which sends request information in name-value pairs over local loopback. As simple as can be. While protocols might be simple, smart management of multiple workers will not be. There are some room for improvement in this area (notice the weird URL for mod_lisp).