This recent performance comparison is one of the articles that got me thinking about FastCGI as on option for long term, low-maintenance OpenACS portability.
My feeling from reading this and all the other papers on FastCGI performance is that though it's probably inferior to AOLServer's well-tuned embedded interpreter like Don says, it's not by any amount I'd spend time worrying about. 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.
I think Don's point about the additional amount of work to core OpenACS development is a much better one to consider. If I felt FastCGI support would be as much work as, say, the database abstraction layer (XQL files etc), I never would have brought it up. I'll try to do some prototyping to address that more concretely. My guess is that without service contracts in place or some sort of agreed upon convention for abstracting web serving and app logic, you're still talking about minimal patching/overloading to move the native AOLServer TCL code to run under FastCGI. Therefore I think keeping a fork in sync without distracting the main OpenACS developers is do-able. It would be nice to have people thinking about writing more portable code to support that, but I don't see this as an either-or proposition.
