Patches

Pull Requests

History

The PHP/FastCGI execution model doesn't allow to identify the real value of FCGI_MAX_CONNS, as it depends on number of running php-cgi backends. FastCGI manager may decide to run more or less backend processes depending on load, but these processes don't communicate each other and can't know how many processes run in the moment.
FCGI_MAX_REQS must be equal to FCGI_MAX_CONNS.
Currently FCGI_MAX_CONNS and FCGI_MAX_REQS return 1 that mean the process can serve only one connection and one request in a moment.
I don't like to fix the issue as it can't be fixed in general without significant complication (shared memory ...)

[2008-09-29 09:25 UTC] arnaud dot lb at gmail dot com

PHP_FCGI_CHILDREN seems a good value for FCGI_MAX_CONNS and FCGI_MAX_REQS. FCGI_MAX_REQS equals FCGI_MAX_CONNS as there is no support for multiplexed connections.
I think these values are relevant only for the backend the request was sent to (e.g. the manager runs 1 php-cgi backend process, asks it for FCGI_MAX_CONNS and run other backend processes depending on that value).

This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
The returned values now depends on PHP_FCGI_CHILDREN passed while launching php-cgi:
Mono-process:
sapi/cgi/php-cgi -b 0.0.0.0:1042
-> FCGI_MPXS_CONNS = 0
-> FCGI_MAX_CONNS = 1
-> FCGI_MAX_REQS = 1
Muli-processes:
PHP_FCGI_CHILDREN=10 sapi/cgi/php-cgi -b 0.0.0.0:1042
-> FCGI_MPXS_CONNS = 0
-> FCGI_MAX_CONNS = 10
-> FCGI_MAX_REQS = 10 ( max concurrent requests ).