[TransWarp] Pre-forking event-driven services
Phillip J. Eby
pje at telecommunity.com
Fri Aug 15 12:06:07 EDT 2003
At 10:30 AM 8/15/03 -0400, Ty Sarna wrote:
>At 08:58 AM 8/15/03 -0400, Phillip J. Eby wrote:
> > [can't escape stupid mod_fastcgi bugs]
>Unless we use the style of FastCGI config we use with our legacy Zopes
>(FastCgiExternalServer), where mod_fastcgi doesn't do process management
>The downside of this is that AFAIK, this *must* be configured in the
>main httpd.conf and not .htaccess files, like the other way can.
That's not the only downside, alas. Another is that the process has to be
started independently, via some mechanism that will handle retries in the
event of failure (e.g. daemontools, or a URLChecker). Otherwise, failure
to start because of a database connection would stop the whole thing cold.
I suppose we live with these conditions right now for the legacy Zope
applications, but that doesn't mean we want to have that situation for
A one-line patch to mod_fastcgi, however, would fix the "jealousy" bug. I
wonder if the maintainers would accept it? Probably not, unless we added
another inscrutable configuration option to control it. ;)
To sum up: the two bugs (from our POV) in mod_fastcgi that we can't work
1. If an application exits on its own initiative, even without an error
condition, mod_fastcgi will restart it. Thus, there is no way to have apps
"wind down" on their own.
2. mod_fastcgi's measurements of load seem flawed: comments in its source
code explicitly state that it's virtually impossible to get a "load" of
higher than 0.5%, but you can only set threshholds at integer %
levels... So, if you use a non-zero threshhold, then processes are killed
at every load check interval. But if you use a zero threshhold, then the
last process is never killed.
The combined effect of these two issues is that there's no way to configure
mod_fastcgi to allow "no processes" to exist, unless you want it to kill
the last process at every check interval! If we could fix either one bug
or the other, we'd be all set. (At least, once we implemented the PEAK
Maybe we can suggest to the mod_fastcgi maintainers that a clean
application exit (i.e., without an error) be allowed to die in peace. That
would be the optimal solution for us, since then we can handle all process
management in our own code, except for the start-on-demand, retry-on-error,
and automatic socket allocation that mod_fastcgi's process manager provides.
More information about the PEAK