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

Reply via email to