Re: ITP: speedy cgi ("persistent" perl scripts)
On Thu, Jul 15, 1999 at 11:58:09PM -0700, sam@daemoninc.com wrote:
> > (i think it's slightly misnamed upstream - you can use this for a
> > lot more than just cgi scripts)
>
> The correct name is "SpeedyCGI". On CPAN it's known as
> "CGI::SpeedyCGI", mainly because it had to be put under the CGI
> directory.
yep, i know. i just think it's more of a "speedyPerl" :) - it took the
persistence idea of mod_perl and generalised it to any perl script.
> CGI is the main thing it was designed for, but yes, it could be used
> in other places where persistent perl is needed. If you have any good
> examples, I'll add them into the documentation.
one thing i have used it for is for scripts which report on user entries
in the passwd file - populate a hash when the script first runs and get
instant responses for every run after that. pretty much any task which
spends a lot of time initialising variables or parsing static or almost
static data before doing any real work can be sped up with speedyCGI.
i have another script which queries a postgres database to find out how
much time a dialup account has used - this one works as both a cgi and
a command-line tool. users look at the web page, i run it from bash.
usually i make several queries one after another, so the effect of
speedy is really noticable.
> > there's also an optional apache module available for this which
> > i haven't included in the package because a) i don't know how to
> > packege apache modules - debian/rules patches or suggestions are
> > welcome, and b) it looks like it's an upstream experiment that is
> > being abandoned.
>
> If you learn anything about the apache module rules, etc, send them
> over and I'll put them into the source. Currently the module is
> compiled into apache -- it's not a DSO. That may be a problem.
ah. that is a problem. in that case, i can't package it for debian. DSO
modules are really the only option for debian - it doesn't make sense to
compile in a non-standard option which not everyone will use.
> The Apache module is *not* being abandoned. It's kind-of new (just
> came out in 1.8), but it's going to be around from now on -- it allows
> SpeedyCGI to get similar performance to mod_perl.
ok, that's good news. i must have misinterpreted the cryptic reference
in the TODO list about whether speedyhandler is still useful or not. i
must admit i thought it was strange that a neat feature like that was
being abandoned...i've only been using speedyCGI 1.5 and hadn't seen it
before.
one thing i am going to try doing with speedyCGI is to add suexec-like
functionality (test if setuid to username. if yes, then test whether
script lives under user's home directory. if not, log security error and
abort). the idea is that each vhost user would get their own copy of the
speedy binary which would be setuid to them.
i'd also like to add in resource limits too - limit memory and cpu in
particular so that runaway or malicious processes can't bring down the
server.
i'm not sure if this will be of general use to anyone else but if i have
any success with this i will submit patches to you.
> But, even without the apache module, it's still quite a bit better
> performance than normal CGI (maybe 10x speed).
yes. another advantage is that user scripts don't get access to mod_perl
and apache internals with speedy. it's unsafe to give vhost customers
access to mod_perl, but speedyCGI is no more unsafe than normal cgi.
craig
--
craig sanders
Reply to: