> 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)
Agree.
> - it seems you can't control the request loop yourself
Yes, but what do you do with this control in fastcgi? Maybe you can
do the same thing in speedycgi in a different way?
> + protocol is more free than the one of FastCGI (is it?)
I'm not sure what you mean by "more free".
> - protocol isn't widespread (almost standard) like the one of FastCGI
Correct. The speedycgi protocol has changed many times, and is documented
only in the C files.
> - seems only to support perl (so far)
> - doesn't seem to support external servers (on other machines) like
> FastCGI (does it?)
Correct. Correct.
I'll add the following plusses for speedycgi:
+ Starts up/shuts down perl processes automatically depending on the load.
Users don't have to get involved at all in starting/stopping proceeses.
+ Assigns requests to processes on an MRU basis
Don't know if these are also true now for fastcgi.
> Question: does speedycgi run a separate interpreter for each script,
> or is there one process loading and calling several perl scripts?
Currently one process == one script. I'm almost done with a version
that allows mutiple scripts in one process.
> If it's a separate process for each script, then mod_perl is sure to use
> less memory.
Depends on the number of scripts you have running at once. And you
have to factor in the whole LRU/shared-memory problem in mod_perl,
which is where this thread originally started.
> 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.
There is the way speedy assigns requests to handlers that is different.
Plus speedy runs the perl processes outside the web-server. And speedy
has a CGI-only mode totally outside the webserver.
> 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 think people should use whichever one is best for their application.
I'm trying to make speedy as good as possible given the time I can
put into it. And I'm trying to communicate to people what it can do.
Beyond that it's up to people to decide which one they want to use.
As I've mentioned on the speedycgi list, I'd like to see some sort of
persistent-perl API developed so that people could write to that API,
then run their script under different persistent-perl environments
without changes. I think that would be better than porting scripts
and modules to every persistent perl environment out there.
> 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.
I think I can help - I'll send a private message.
