Description:
------------
I am using PHP-FPM with the "ondemand" process model, and

pm.max_requests = 500
pm.process_timeout = 120
pm.max_children = 50

(If the exact reasoning why I am using this process model or these numbers matters, let me know and I'll amend the bug description.)

From time to time, my server faces load spikes that can lead to a few dozen PHP-FPM processes running simultaneously. The baseline load is about 2 PHP-FPM reqs/s.

What I have observed is that after the spikes, I have a large number of FPM processes that never go away. I would have expected that some time after handling a load spike, the number of running processes should be very low, around what is needed to work the baseline load.

I think the explanation is that PHP-FPM allocates work to worker processes in a round-robin fashion. Thus, every single running process gets something to do before the 120s timeout is reached. This is supported by the fact that on the status page, the number of requests processed is roughly the same for all children.

I still have no clue why the max_requests does not seem to help. After some time, all the processes should have served the 500 requests an be terminated. Unless a replacement is started immediately (regardless of load), this should make the number of running (but idle) processes return to "a few".

So, my request is:

- Can anybody confirm processes are scheduled round-robin?
- When max_requests is reached, is a replacement process launched immediately, or is it up to the process management model to launch a replacement when it sees fit?
- Would it be possible to change the scheduling model to "use the oldest or youngest idle child" without severely impacting scheduling performance?