thread/process less’’ 
I think your objection to this is basically because of apache problems,
not really problems with process spawning. Apache process spawning is
problematic because of apache itself. Each process is taking up system
resources, doing very little or nothing at all (especially true with
keep-alive connections). Since apache is a memory hog, this causes
problems, I’ve had problems with machines going into swap because of
this. If you don’t have fastcgi in Apache, the problem is much more
noticable, since each process takes up much more memory with mod_php
instead of using fastcgi in the backend.
P.s. doesnt lighttpd already have “apache” style process spawning for
fastcgi? The config options for fastcgi include min-procs, max-procs.
This should be an equivalent with apaches MinSpareServers,
MaxSpareServers, MaxClients but relevant only to fastcgi (albeit
smaller, 1-8 is something reasonable).
On 7/16/08, Tit P. [email protected] wrote:
P.s. doesnt lighttpd already have “apache” style process spawning for
fastcgi? The config options for fastcgi include min-procs, max-procs. This
should be an equivalent with apaches MinSpareServers, MaxSpareServers,
MaxClients but relevant only to fastcgi (albeit smaller, 1-8 is something
reasonable).
yes, in 1.4.x - in 1.5.x adaptive process spawning has been
removed/not included.
also, i believe it is considered “broken” by the lighty community, so
it’s not very useful to begin with.
php-fpm to me is the right type of tool for the job. originally i had
a “wishlist” item for something that would have been a fastcgi proxy
layer - essentially everything php-fpm provides… so php-fpm to me is
a godsend, as soon as Andrei finishes the process spawning work, it
will make my life so much more enjoyable - no more wasting resources
trying to determine manually how many engines to have sitting around,
etc…
On 7/16/08, Almir K. [email protected] wrote:
mod_suphp can do that as well.
I ran suphp for a bit. it could not handle the load on my servers. it
looks like it essentially runs an actual php cgi process to handle
each request. That’s hardly scalable. Oh yeah - it requires Apache.
Puke.
but is apache style process spawning really a good idea? i mean i’m
replacing apache with nginx because the idea of apache’s scaling is
‘‘thread/fork as much as you can, as soon as you can and not a
thread/process less’’ 
Andrei calls it apache style. Basically I think it’s just a basic
“Have $x number of engines at start, have max of $y engines, keep $z
engines idle” etc…
It’s not really a straight apples to apples comparison of apache vs.
nginx style of handling processes… that’s just the title he’s given
it on how you define the threshholds, I believe.