Hello Sam and others
If I haven't overseen, nobody so far really mentioned fastcgi. I'm
asking myself why you reinvented the wheel. I summarize the
differences I see:
+ perl scripts are more similar to standard CGI ones than with
FastCGI (downside: see next point)
- it seems you can't control the request loop yourself
+ protocol is more free than the one of FastCGI (is it?)
- protocol isn't widespread (almost standard) like the one of FastCGI
- seems only to support perl (so far)
- doesn't seem to support external servers (on other machines) like
FastCGI (does it?)
Question: does speedycgi run a separate interpreter for each script,
or is there one process loading and calling several perl scripts? If
it's a separate process for each script, then mod_perl is sure to use
less memory.
As far I understand, IF you can collect several scripts together into
one interpreter and IF you do preforking, I don't see essential
performance related differences between mod_perl and speedy/fastcgi
if you set up mod_perl with the proxy approach. With mod_perl the
protocol to the backends is http, with speedy it's speedy and with
fastcgi it's the fastcgi protocol. (The difference between mod_perl
and fastcgi is that fastcgi uses a request loop, whereas mod_perl has
it's handlers (sorry, I never really used mod_perl so I don't know
exactly).)
I think it's a pity that during the last years there was such little
interest/support for fastcgi and now that should change with
speedycgi. But why not, if the stuff that people develop can run on
both and speedy is/becomes better than fastcgi.
I'm developing a web application framework (called 'Eile', you can
see some outdated documentation on testwww.ethz.ch/eile, I will
release a new much better version soon) which currently uses fastcgi.
If I can get it to run with speedycgi, I'll be glad to release it
with support for both protocols. I haven't looked very close at it
yet. One of the problems seems to be that I really depend on
controlling the request loop (initialization, preforking etc all have
to be done before the application begins serving requests, and I'm
also controlling exits of childs myself). If you're interested to
help me solving these issues please contact me privately. The main
advantages of Eile concerning resources are a) one
process/interpreter runs dozens of 'scripts' (called page-processing
modules), and you don't have to dispatch requests to each of them
yourself, and b) my new version does preforking.
Christian.
--
Web Office
Christian Jaeger
Corporate Communications, ETH Zentrum
CH-8092 Zurich
office: HG J43 e-mail: [EMAIL PROTECTED]
phone: +41 (0)1 63 2 5780 [EMAIL PROTECTED]
home: +41 (0)1 273 65 46 fax: +41 (0)1 63 2 3525