Jim,

(still responding on-list, hoping for other people to chime in ;-)

>If I configure Apache to spawn several son processes to repsond to http
>requests (therefore I am in 'multi-process' land instead of 'multi-thread'
>land), and I have a FASTCGI module doing the processing to generate the
>response to each son-process, am I better or worse off, performance-wise,
>than using a Java servlet to respond to each son-process?  In the latter
>scenario, wouldn't I being using both multi-processing of Apache sons and
>multi-threading of the servlet?  What does that really buy me?  Has you
>indicated, with Java you would probably end up 'forking' to a routine
>written in TRANSACT or some other program that interfaces easily to IMAGE.
>Does this become a matter of pick your poison?

Hmmm. Let me try to shed some more light on FastCGI and JServ, as they
seem to have pretty similar architectures (except for the different API
and language). Note that my memory on FastCGI is fading, correction are
highly welcome whenever I start to write nonsense!

FastCGI:

  httpd (parent)
    httpd (child pool)
     ...
    httpd (child pool)  --> request --> fcgi listener/server -\
     ...               <-- response <-------------------------/

The httpd parent awakes one of the httpd children to handle an
incoming browser request; with the help of mod_fcgi the request
is passed on to the fastcgi listener/server process, which in
turn generates a response, passes it back to the httpd child,
which returns it to the browser.

The Apache httpd child pool keeps processes on standby and alive
for more than a single request (for efficiency reasons). The fastcgi
listener/server also stays alive to handle more than a single web
page request (and can keep databases open, for example). I don't
recall whether the fcgi listener/server is a single process or also
maintains a pool of workers.

Apache Jserv:

  httpd (parent)
    httpd (child pool)
     ...
    httpd (child pool)  --> request --> jserv listener/server -\
     ...               <-- response <--------------------------/

The httpd parent awakes one of the httpd children to handle an
incoming browser request; with the help of mod_jserv the request
is passed on to the ApacheJServ listener/server process, which in
turn generates a response, passes it back to the httpd child,
which returns it to the browser.

The Apache httpd child pool keeps processes on standby and alive
for more than a single request (for efficiency reasons). The Jserv
listener/server also stays alive to handle more than a single web
page request (and can keep databases open, for example). It can run
servlets in multi-threaded fashion i.e. deal with multiple httpd
conversations (quasi-)concurrently. Moreover, the ApacheJServ does
host one or more different servlets (not sure, but fastcgi might
need separate server jobs/processes for that).

Both, FastCGI and JServ, can use TCP/IP between httpd and the fcgi
or ApacheJServ listener/server "engine". This does allow to run the
web server and the fcgi/JServ engine on the same or different boxes.
For example (not typical for real life), you could have the httpd
processes from the WebWise Secure Apache on MPE/iX talk to FastCGI
or ApacheJServ processes/servlets on Unix/NT/Linux/Solaris/OS400,
which in turn might access local data on their respective platform
or use e.g. JDBC to access ImageSQL/Allbase/Oracle/SQL-Server/etc
on one or more platforms. Again, this is not meant as an example
typical for real-life, just to show degrees of freedom. (You could
also have the Apache run on other platforms and the servlets on
the 3000, for example).

Does this answer all of your above questions? Probably not ;-)

If you can get Transact plugged under FastCGI, you can probably
drop the intermediate Java layer and some associated overhead. On
the other hand, that would reduce the flexibility to move code to
other machines/platforms (eg for load balancing or access to their
specific resources). Regarding the multi-threading in ApacheJServ:
not sure if (or how much) throughput it adds. I don't know how the
fcgi server handles concurrent requests from httpd siblings. The
multi-threading/servlet pooling of the JServ engine can be quite
handy for getting resource pooling (eg JDBC connections or Telnet
sessions) without significant programming effort (beyong tagging
the servlet as "implements SingleThreadModel" and configuring the
minimum/maximum pool size in JServ config files).

Regarding "pick your poison"... I am not sure what this means, but
I guess it addresses the issue of "too many options in the trendy
technology world... is there a 'best' solution? if so, how to find
it? and will it still exist next week?"...

I can only speak on the approaches I played with, and wether they
worked reasonably well (for me). However, I always have to add the
disclaimer that I'm not using them in large-scale/big projects.
Just for a couple of small tools used by me and my colleagues. On
the other hand, this "scale" is probably a good one to get started
and collect (good or bad) experiences with the new technologies.

I'm still hoping for others to join the thread and share insight.

;-) Lars


PS: I sometimes wonder if it's better to pick a reasonably simple
and stable (and Open Source) technology and start using it, instead
of evaluating lots of architectures-du-jour and waiting for some
ultimate solution to show up. (but maybe I am just overwhelmed by
the ongoing flood of new technologies/architectures/tools ;-)