Edit report at http://bugs.php.net/bug.php?id=52569&edit=1

 ID:                 52569
 Comment by:         mplomer at gmx dot de
 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

 New Comment:

Patch version 5:

- Added missing fpm_globals.is_child check (proposed by jerome)

- Implemented "max children reached" status counter.

- Fixed missing last_idle_child = NULL; in
fpm_pctl_perform_idle_server_maintenance which caused the routine to
shutdown only one (or a few?) processes per second globally instead per
pool, when you have multiple pools. I think this was not the intention,
and it's a bug.


Previous Comments:
------------------------------------------------------------------------
[2010-08-27 08:38:34] f...@php.net

Updates to come:



1- there is a bug. after fork, child process seems to run code reverved
to the 

parent process:



Aug 27 08:32:30.646905 [WARNING] pid 4335, fpm_stdio_child_said(), line
143: 

[pool www_chroot] child 4450 said into stderr: "Aug 27 08:32:30.628866
[DEBUG] 

pid 4450, fpm_pctl_on_socket_accept(), line 529: [pool www_chroot] got
accept 

without idle child available .... I forked, now=22184178.981102"



2- the 1s max delay before resetting the fpm_pctl_on_socket_accept() is
in 

theory enough. But I prefer to set a much smaller specific timer (~1ms)
just in 

case. Imagine there is a bug and children becomes to segfault and it's
not 

restarted. There will be a 1s delay (max) before it's forked again. I
now it's 

the worst case scenario.

------------------------------------------------------------------------
[2010-08-27 08:31:11] f...@php.net

here is a new revision:



1- I restore the backlog value check at startup. It's been simplified.
If it's 

lower than 128, it's set to 128. I kept also the change of the backlog
default 

value from -1 to 128. As the ondemand will certainely end up in trunk,
it's not 

a violation of the 5.3 code.



2- you were right for the "else if (wp->config->pm ==
PM_STYLE_ONDEMAND)". I 

thought there were a "if (wp->config->pm == PM_STYLE_STATIC)" on the
front of 

the block



3- I change the libevent callback on pool listen_socket to prevent CPU
burns. If 

max_childre is triggered, the callback function will be set up at next
process 

maintenance call (every 1s).

------------------------------------------------------------------------
[2010-08-27 08:27:20] f...@php.net

The following patch has been added/updated:

Patch Name: fpm-ondemand.v4.patch
Revision:   1282890440
URL:       
http://bugs.php.net/patch-display.php?bug=52569&patch=fpm-ondemand.v4.patch&revision=1282890440

------------------------------------------------------------------------
[2010-08-26 00:27:45] f...@php.net

For information, the listen.backlog default value has been changed from
-1 to 

128 into trunk recentely: http://svn.php.net/viewvc?

view=revision&revision=302725



This changed won't be applied to 5.3 branch so as the ondemand process
manager 

as it's a (big ?) new feature. It could be discussed.



I like the listen_backlog adjustment. It was maybe not perfect but
setting it to 

0 will make the on demand PM not working.



for the "else if" fix, you have to add an "else {}" in all the cases. If
there 

is a bug somewhere else, it's not advised to have a case which could not
be 

checked.



it looks great. Can you also provides test results ?



thx a LOT for you help and your time making PHP better.

------------------------------------------------------------------------
[2010-08-26 00:15:47] mplomer at gmx dot de

I did some finetuning and cleanups in the fpm-ondemand-pm-v3.patch:



set listen_backlog default to 128 (to be discussed?)



removed listen_backlog adjustment (I considered that it is enough to
leave the default at 128, a greater value is mostly ignored by the
system anyway, and the number of requests in the backlog has rather
nothing to do with max_children. If you do not agree with this, feel
free to restore the old behaviour :-) )



renamed ondemand_process_timeout to process_idle_timeout (it's better, I
think)



fixed "else if (wp->config->pm == PM_STYLE_ONDEMAND)" in fpm_conf.c (was
only "else" before)



removed config->pm_(start/min_spare/max_spare)_servers = 0; ... in
fpm_conf.c (should not be used anyway when pm = ondemand)



log libevent version in fpm_event_init_main



updated some comments in sample config

------------------------------------------------------------------------


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

    http://bugs.php.net/bug.php?id=52569


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=52569&edit=1

Reply via email to