grzegorz.nosek at gmail.com
Mon Mar 9 09:28:21 MSK 2009
On nie, mar 08, 2009 at 03:20:59 -0800, mike wrote:
> On Sun, Mar 8, 2009 at 2:40 PM, Grzegorz Nosek <grzegorz.nosek at gmail.com> wrote:
> > spawn-fcgi doesn't care about php engines, CGI processes and whatnot.
> > If your bug report contains the word PHP, then it _certainly_ isn't
> > about spawn-fcgi. There is *never* a single point in time when both
> > spawn-fcgi and php-fcgi run side by side (one simply becomes the other).
> Wrong. Well, partially.
> spawn-fcgi has -C *for PHP only* and I believe I saw it should
> inherit/understand the PHP_MAX_FCGI_REQUESTS environment variable. So
> it does have PHP-specific configuration (-C)
-C num is a fancy way of setting PHP_FCGI_CHILDREN=num. spawn-fcgi simply
passes the environment down to php-fcgi and does not care one bit for
*any* PHP_* env. variables (-C is pure convenience).
Have you seen the perl launcher for fcgiwrap on my website? It is
(grossly simplifying) a drop-in replacement for spawn-fcgi and you could
run php-fcgi behind it if you so wished.
> > Are you positive you can reproduce a bug using spawn-fcgi and not using
> > php -b? That would be mildly interesting (another one in the endless
> > stream of PHP bugs).
I guess you could try reporting it on the PHP bugtracker...
> I used PHP_MAX_FCGI_REQUESTS=100 or whatever the variable was with php
> -b and hammered the test site. I saw the process ID's changing in my
> process list, i.e. when it hit 100 requests, the child was terminated
> and a new one was created.
> With spawn-fcgi I could throw it thousands of requests and the
> processes never terminated themselves.
Maybe you haven't exported the variable for the php process to see
(somehow). Anyway, you'd probably see the exact same behaviour with my
> While not a showstopper it was a lacking feature of php's fastcgi
> support to prevent memory leaking.
Which, again, has hardly anything to do with spawn-fcgi. Or Nginx, for
that matter (drifting way off topic).
More information about the nginx