php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #45522 FCGI_GET_VALUES request does not return supplied values
Submitted: 2008-07-15 16:02 UTC Modified: 2008-10-21 03:29 UTC
From: arnaud dot lb at gmail dot com Assigned: dmitry (profile)
Status: Closed Package: CGI/CLI related
PHP Version: 5.3CVS-2008-07-15 (CVS) OS: *
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: arnaud dot lb at gmail dot com
New email:
PHP Version: OS:

 

 [2008-07-15 16:02 UTC] arnaud dot lb at gmail dot com
Description:
------------
FastCGI specifies that a FastCGI application may return the values supplied by a FCGI_GET_VALUES request.

Actually the FastCGI SAPI returns all standard values (FCGI_MAX_CONNS, FCGI_MAX_REQS, FCGI_MPXS_CONNS), *except* those supplied.

Also, it seems that the returns values does not reflect the actual configuration (e.g. FCGI_MAX_CONNS and FCGI_MAX_REQS are always 1).

Reproduce code:
---------------
Requesting the FCGI_MAX_CONN value using a FCGI_GET_VALUES record in the FastCGI protocol.


Expected result:
----------------
Requesting the FCGI_MAX_CONN returns FCGI_MAX_CONN value.

Actual result:
--------------
Requesting the FCGI_MAX_CONN returns FCGI_MAX_REQS and FCGI_MPXS_CONNS values but not FCGI_MAX_CONN.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-09-29 08:35 UTC] dmitry@php.net
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).
 [2008-10-21 03:29 UTC] lbarnaud@php.net
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 ).
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Oct 31 22:01:27 2024 UTC