I asked on the AOLServer mailing list about how hard it would be to provide FastCGI support directly in AOLServer, and in the course of discussing it Dossy volunteered to do a first pass. (I suspect some previous haranging by Andrew P helped with this)
Al, I believe the above answers all three of your questions. Although taking it from prototype to production might require additional AOLServer hacking skills (as will support), I suspect those exist in this community. Also, given FastCGI's age and stability, I suspect that the support load will be quite manageable once the initial work is done (unlike mod_aolserver etc)
FWIW, I think the only way to productively move portable.nsd forward is for someone with _specific_ requirements to underwrite it. Basically, it needs a client/project so that you can decide how (un)important some of the lesser used AOLServer/OpenACS functionality is and you can productively narrow the scope. Supporting the entire legacy API required to run all of OpenACS doesn't make sense when it's often easier to rewrite legacy/deprecated code in more modern/supported idioms. I discovered that supporting OpenACS via portable.nsd is an overwhelming task compared to supporting a specific (and ideally, recently written) OpenACS application. For that reason, I'm more optimistic about Dossy's prototype which he said he'd deliver sometime in March.
Talli et al,
I've read that one recommended way to scale mod_perl is to separate out static web serving from the dynamic part (which people have proposed here with pound/thttpd?). You run a front-end Apache instance with mod_proxy and a heavy-weight backend with mod_perl. I suspect that recommendation is good anecdotal evidence that the reverse proxy overhead is negligible. I've never had a problem with it, but haven't deployed it under extreme load.
