On nie, mar 08, 2009 at 02:17:17 -0800, mike wrote:
spawn-fcgi was not properly recycling php engines (i.e.
PHP_MAX_FCGI_REQUESTS or whatever) when i was using it, i was able to
validate it. i wound up going back to a custom php -b solution until i
found php-fpm. so there -are- bugs.
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).
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).
Can Grzegorz get in here and you two can hash out how it works? 
Trying my best
Best regards,
Grzegorz N.
On Sun, Mar 8, 2009 at 2:40 PM, Grzegorz N.
[email protected] 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)
This is a thread I started a while back:
http://forum.lighttpd.net/topic/5906
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).
Yes.
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.
While not a showstopper it was a lacking feature of php’s fastcgi
support to prevent memory leaking.
On Sun, Mar 8, 2009 at 3:45 PM, Icy – [email protected] wrote:
Did you spawn it with “PHP_FCGI_MAX_REQUESTS=1000 spawn-fcgi
more_args_here”?
Maybe there’s a way to do this via php.ini, haven’t checked.
Yeah, I am pretty sure I even may have dumped $_ENV or phpinfo() to
see all the environment variables available and it wasn’t there.
I’m happy with php-fpm for now though… so spawn-fcgi’s big selling
point for me right now is for CGI.
BTW: there is the -F option to specify the number of children to spawn
(non-php-style). Sorry, I was wrong before when I said this isn’t
possible.
Okay, well I don’t know how this fits with Grzegorz’s stuff.
He gave me a command line (I haven’t tried it yet) and I don’t know if
-F would be better or not.
On nie, mar 08, 2009 at 03:20:59 -0800, mike wrote:
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).
Yes.
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
primitive launcher.
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).
Best regards,
Grzegorz N.
mike wrote:
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.
While not a showstopper it was a lacking feature of php’s fastcgi
support to prevent memory leaking.
Did you spawn it with “PHP_FCGI_MAX_REQUESTS=1000 spawn-fcgi
more_args_here”?
Maybe there’s a way to do this via php.ini, haven’t checked.
BTW: there is the -F option to specify the number of children to spawn
(non-php-style). Sorry, I was wrong before when I said this isn’t
possible.
On Sun, Mar 8, 2009 at 10:28 PM, Grzegorz N.
[email protected] wrote:
-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).
All I’m saying is the statement was spawn-fcgi has nothing to do with
PHP. It does not in general but it does have built-in some PHP
helpers, so it was designed with PHP in mind.
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.
I’m planning on trying the spawn-fcgi + fcgiwrap for CGI soon, and
stick with php-fpm for now for PHP…
I guess you could try reporting it on the PHP bugtracker…
Wasn’t a problem with PHP. Was some sort of issue with spawn-fcgi not
passing the environment variable or something. Running vanilla “php
-b” with the proper environment variables worked perfectly.
Yeah, this has got off topic for nginx.
Back to on topic would be discussing the easiest/cleanest way to run
CGI scripts under nginx, I’d prefer using spawn-fcgi rather than the
perl launcher I think. I need to give it a try when I have some time.
On pon, mar 09, 2009 at 12:05:58 +0100, Icy – wrote:
Grzegorz N. wrote:
Run them all on the same socket.
This could be a problem with tcp sockets
You mean some compatibility/performance problems or ‘it doesn’t work’
problems? Frankly, I am not aware of what could go wrong by sharing
a tcp socket but not a unix domain socket. May I kindly request
enlightenment?
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).
Very well explained!
Thanks Maybe spawn-fcgi should come with a graph or something to show
the relationships between processes to avoid confusion.
Best regards,
Grzegorz N.