Edit report at https://bugs.php.net/bug.php?id=52569&edit=1
ID: 52569
Comment by: damien at commerceguys dot com
Reported by: mplomer at gmx dot de
Summary: Implement "ondemand" process-manager (to allow zero
children)
Status: Closed
Type: Feature/Change Request
Package: FPM related
PHP Version: 5.3.3
Assigned To: fat
Block user comment: N
Private report: N
New Comment:
As already mentioned in [2011-09-14 21:57 UTC] shadow+dphp at la3 dot org:
This seems to be missing a:
PHP_ADD_BUILD_DIR(sapi/fpm/fpm/events)
in the config.m4 file.
Previous Comments:
------------------------------------------------------------------------
[2011-10-08 21:06:50] [email protected]
This bug has been fixed in SVN.
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
I finally commit this feature to svn to 5.3 and 5.4 branches.
I'd like to thanks everyone here !! (I accept payments if you want :p)
Please test it and re-open of you discover anything wrong.
++ fat
------------------------------------------------------------------------
[2011-10-08 21:03:46] [email protected]
Automatic comment from SVN on behalf of fat
Revision: http://svn.php.net/viewvc/?view=revision&revision=317922
Log: - Implemented FR #52569 (Add the "ondemand" process-manager to
allow zero children)
------------------------------------------------------------------------
[2011-09-17 10:01:33] uros dot gruber at gmail dot com
I tested it on two servers on FreeBSD, both amd64 kernel and the strange thing
is
that on one server I can't get it build with kqueue support. While ./configure
I
can clearly see kqueue support to yes but then when testing config I have an
error saying "ondemand process manager can ONLY be used when events.mechanisme
is
either epoll (Linux) or kqueue (*BSD)." Is there anything I might missed while
building?
regards
------------------------------------------------------------------------
[2011-09-14 21:57:46] shadow+dphp at la3 dot org
Since there has been no activity on this issue for a while, and I think it
would be *very* good to have this ondemand process manager on stable releases
as soon as possible, I have decided to try the patch by myself and report the
results.
Also, I am a die-hard Debian user, so I tried the patch (v11-5.3) with the
latest available Debian packages in sid (php 5.3.8 + a number of other patches).
I found a minor issue at compile time, due to the fact that the
"sapi/fpm/fpm/events" folder is not created by the Makefile within the build
directory structure (if you specify a build directory separated from the
sources). I solved this issue easily by inserting a new line in the
"sapi/fpm/Makefile.frag" file:
$(builddir)/fpm:
@mkdir -p $(builddir)/fpm
+ @mkdir -p $(builddir)/fpm/events
After this minor correction everything compiled well. Thus, I proceeded to run
some tests, using apache (Apache/2.2.20) + mod_fastcgi (2.4.7~0910052141-1) as
the php5-fpm frontend. In this setup, I created a separate virtual host in
front of each pool, and used the following apache config in there:
<IfModule mod_fastcgi.c>
ScriptAlias /fcgi-bin/
"/var/www/virtual/pool.test.com/fcgi-bin/"
FastCGIExternalServer
/var/www/virtual/pool.test.com/fcgi-bin/php-cgi \
-socket /var/lib/php5/pools/pool.test.com
AddHandler php-fastcgi .php
Action php-fastcgi /fcgi-bin/php-cgi
</IfModule>
The sockets themselves are owned by the apache's user (www-data), whereas the
php interpreters run under a different user for each pool.
Results:
General
- Pool has to start with 0 children - OK
- The "ondemand" pm can be enabled - OK
- All three pm's can be enabled at the same time (for different pools,
obviously) - OK
Concurrent requests
- Children has to be forked immediately on new requests without delay - OK
- Idle children has to be killed after pm.process_idle_timeout + 0-1s - OK
- When there are more than one idle children, kill only one per second PER POOL
- Almost OK
(only does it if pm.process_idle_timeout > 1)
Reaching pm.max_children limit
- No more processes has to be created - OK
- Requests have to wait until one child becomes idle and then get handled
immediately without further delay - OK
- When limit is reached, issue a warning and increase status counter (and do
this only once) - OK:
[14-Sep-2011 23:16:07] WARNING: [pool site1.test.com] server reached
max_children setting (4), consider raising it
- Warning is re-issued after children count decreases and hit the limit again -
OK
CPU burns
- When reaching max_children limit, pause libevent callback and reenable it in
the maintenance routine, to avoid CPU burns - OK/DUNNO
CPU usage does not spike under these conditions, but I do not know anything
about libevent.
- When children takes too long to accept() the request, avoid CPU burn -
OK/DUNNO
Tried with "ab -c300", no CPU burns observed.
Observations
- "ondemand" spawns new children *way* faster than "dynamic" does
- each "dynamic" process consumes about 0.1% cpu time while idle, whereas idle
"ondemand" and "static" pools do not impose any load at all.
Problems
- pm.min_spare_servers default value if unspecified in the pool config is 0,
whereas the default pm is "dynamic".
- pm.max_spare_servers default value if unspecified in the pool config is 0.
Final note: Jerome, the ondemand process manager is *amazing*. If it combines
well with the global maximum number of processes from #55166 , this is
effectively the holy grail of php for virtual hosting companies. Big big
congratulations and do not hesitate to ask me for any further info/tests that
you need to make this a reality!
------------------------------------------------------------------------
[2011-07-15 08:47:47] dbetz at df dot eu
Hi jerome,
the test ist successful for me.
Everything works fine with PHP5.3.7rc4-dev and ondemand patch v11
Greets,
Daniel
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=52569
--
Edit this bug report at https://bugs.php.net/bug.php?id=52569&edit=1
