Edit report at https://bugs.php.net/bug.php?id=52569&edit=1
ID: 52569 Updated by: f...@php.net 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: my mistake. it's now fixed Previous Comments: ------------------------------------------------------------------------ [2011-10-09 07:57:23] damien at commerceguys dot com 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. ------------------------------------------------------------------------ [2011-10-08 21:06:50] f...@php.net 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] f...@php.net 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! ------------------------------------------------------------------------ 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