[TransWarp] Pre-forking event-driven services
Phillip J. Eby
pje at telecommunity.com
Fri Aug 15 09:54:23 EDT 2003
At 08:58 AM 8/15/03 -0400, Phillip J. Eby wrote:
>Meanwhile, if you configure so as to be able to shut down running
>processes without mod_fastcgi starting them again, it will play a fun game
>called, "start processes and then kill them before they do anything",
>whenever processes are started just before its periodic "kill idle
>processes" event. (The slower the process start, the worse this hurts,
>because the the window in which it can occur gets larger, and because more
>work is wasted when it does happen.)
After a little investigation, I've realized that it doesn't matter how you
configure mod_fastcgi: if processes exit on their own, for *any* reason
except mod_fastcgi killing them, they will be marked for restart. In other
words, you *can't* configure mod_fastcgi such that you can shut down
running processes. Period. :(
It looks as though we may want to define a signal used to tell the PEAK
process manager to stop its children and then "play dead". Then, assuming
we configure mod_fastcgi to always have at most one process running,
everything should work out as we'd like. Although mod_fastcgi will
probably kill our "frozen" process manager at its next idle-killing
interval, it won't restart it if no requests are coming in.
Unfortunately, this still doesn't fix the "start-and-kill" problem. More
on this later.
More information about the PEAK
mailing list