Edit report at https://bugs.php.net/bug.php?id=52569&edit=1
ID: 52569
Comment by: shadow+dphp at la3 dot org
Reported by: mplomer at gmx dot de
Summary: Implement "ondemand" process-manager (to allow zero
children)
Status: Analyzed
Type: Feature/Change Request
Package: FPM related
PHP Version: 5.3.3
Assigned To: fat
Block user comment: N
Private report: N
New Comment:
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!
Previous Comments:
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
[2011-07-14 18:47:05] [email protected]
Here is a complete new release of the ondemand patch: the version 11.
I've rewritten entierly the event part in order to have access to the following
mechanism:
select (posix)
poll (posix) <- was the mechanism in used before
epoll (linux)
kqueue (*bsd)
/dev/poll (solaris)
port (solaris)
all this mechanism supports classic Level-Triggered events which is not adapted
for what we need for the ondemand patch.
epoll and kqueue also supports Edge-Triggered events which suits very well the
ondemand patch needs.
choice is made automatically by detection and the best is used. You can
overrride the detection by setting events.mechanism in [global]
So now, ondemand PM will only works if kqueue or epoll is selected. It will
only work on Linux and *BSD. But, it should work has expected without the
previous drity trick: events.delays or pm.min_delay_between_fork.
so, to test it:
get the lastest 5.3 or 5.4 snapshot, apply the patch and:
./vcsclean
./buildconf
./config.nice (or configure ... --enable-fpm)
make
set pm to ondemand and run
/* enjoy */
------------------------------------------------------------------------
[2011-07-14 18:38:24] [email protected]
The following patch has been added/updated:
Patch Name: fpm-ondemand.v11-5.3.patch
Revision: 1310683104
URL:
https://bugs.php.net/patch-display.php?bug=52569&patch=fpm-ondemand.v11-5.3.patch&revision=1310683104
------------------------------------------------------------------------
[2011-07-14 18:27:18] [email protected]
The following patch has been added/updated:
Patch Name: fpm-ondemand.v11.patch
Revision: 1310682438
URL:
https://bugs.php.net/patch-display.php?bug=52569&patch=fpm-ondemand.v11.patch&revision=1310682438
------------------------------------------------------------------------
[2011-07-11 04:09:43] [email protected]
As 5.3.7 is in a RC release process, only bugfixes are going there until 5.3.7
is
out.
so the ondemand will be added in 5.3.7+ and 5.4 and marked as experimental.
------------------------------------------------------------------------
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
