php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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 Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
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

Add a Patch

Pull Requests

Add a Pull Request

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: Wed Apr 24 02:01:30 2024 UTC