Curtis wondered...

>Is PHP better than FastCGI/Servlets?  (If so, why?)

Well, it depends :-)  At least it is different.

As far as I understand (corrections welcome), PHP is similar to the
Perl module for Apache, i.e. you can compile mod_php (or mod_perl)
into the httpd web server program. This allows Apache to execute the
scripting tasks inside the httpd server process. No child process
creation is needed as in CGI programming.

On the other hand, FastCGI and Apache JServ only add a small piece
of communication code into the httpd program (mod_fastcgi/mod_jserv)
and let the httpd process talk to a separately launched FastCGI or
JServ process, the latter providing the Java Servlet engine. Unlike
CGI, the FastCGI or JServ process is not short-lived, handling only
a single client request. By stayling alive to handle many client
requests, the overhead of process creation/deletion, database opens,
etc. is reduced. (The same is probably true for mod_perl and mod_php
as Apache keeps a pool of httpd server children alive).

The communication between httpd and FastCGI or JServ engine takes
place using TCP (FastCGI also seems to allow named pipes), adding
a certain amount of overhead, but also some flexibility at the same
time. The web server and FastCGI or JServ processes do not need to
run on the same machine (but they can do). So it is possible, for
example, to run Apache on a Linux box (maybe even Apache with SSL
capabilities), or maybe even a group of web server machines, and
let them talk to the FastCGI or JServ processes running on the 3000,
where the data or business logic might reside.

This doesn't answer the question, whether PHP is better than FastCGI
or Servlets, but hopefully gives some ideas about pros and cons of
these different solutions. Maybe other people can share their thoughts
or experiences regarding complexity, robustness, etc...

Oh, while talking on Servlets... Apache JServ is not the only engine
to host Java Servlets. You can also run a Java Web Server like Jigsaw,
Enhydra, or many others, when intending to run servlets on the 3000.
A web server written in Java would not need a separate process to run
the servlets, it simply loads them as part of the http server itself.
Kind of analogous to QWEBS calling COBOL subroutines from an NMXL.

Too much choice? Probably the price of open-ness...

Lars.