Performance tuning PHP-FPM: How to tune the number of child processes

Question

pm = dynamic
pm.max_children = 20
pm.start_servers = 10
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 1000

Assume using above configuration. Is it possible to know the following?

1. How many outstanding requests in the request queue pending to be served?
2. Average latency that a request wait in the queue before it is being served?

Answer 1

But the top question - "how to tune the number of PHP-FPM child processes" - can be answered more simply, as 'as many as can fit in memory'. Investigating my very small VPS, I can see:

$ grep memory_limit /etc/php/7.4/fpm/php.ini 

    memory_limit = 128M

PHP's default memory limit of 128 Megabytes is far more than I'm using.

$ free -m
           total used free shared buff/cache available
    Mem:     976  468   68      0        439       369
    Swap:      0    0    0

This VPS has 369 MB Available, so it wouldn't make sense to try and have more PHP instances than could fit.

Putting the PHP Max Mem and Mem Free numbers into variables and dividing avail/maxmem, gives:

$ PHPSIZE=`grep memory_limit /etc/php/7.4/fpm/php.ini | tr -dc '0-9'`
$ AVAIL=`free -m | grep "^Mem" | rev | cut -d' ' -f 1 | rev`
$ echo "scale=3;$AVAIL/$PHPSIZE" | bc

    2.875

So in this case the 369 available megabytes could only accomodate 2 128-Megabyte php instances, assuming memory_limit maximum reflects actual maximum memory needed.

This can be investigated with the memory_get_peak_usage() function.

see also:

• https://linux.die.net/man/1/free
• https://linux.die.net/man/1/bc
• https://www.php.net/manual/en/function.memory-get-peak-usage.php

Answer 2

1. Assuming Linux unix sockets, the pending connections can seen with ss (package: iproute2) and netstat (package: net-tools).

Using ss;

$ ss -lf unix src /run/php\*

will show output like

Netid      State    Recv-Q Send-Q  Local Address:Port                Peer Address:Port      Process      
u_str      LISTEN   5      4096    /run/php/php7.4-fpm.sock 7082746  * 0           

Netstat, instead, will show a list:

$ netstat -xpa | grep -E "^(Active|Proto)|php"

Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node   PID/Program name     Path
unix  2      [ ACC ]     STREAM     LISTENING     7066676  1021364/php-fpm: ma  /run/php/php7.4-fpm.sock
unix  3      [ ]         STREAM     CONNECTED     7068154  1021391/php-fpm: po  /run/php/php7.4-fpm.sock
unix  3      [ ]         STREAM     CONNECTED     7067205  1021406/php-fpm: po  /run/php/php7.4-fpm.sock
unix  3      [ ]         STREAM     CONNECTED     7067203  1021407/php-fpm: po  /run/php/php7.4-fpm.sock

2. Latency.

This isn't so straightforward; There are 2 approaches, benchmarking and logging.

Benchmarking can use a wide variety of tools, for example apache bench or siege

Example ab usage:

$ ab -c 50 -n 100 "http://hp/delay.php"

will open 50 simultaneous connections and make 100 requests (2 each). I produces useful output like:

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   1.5      2       4
Processing:  1002 2079 716.5   2010    3130
Waiting:     1002 2079 716.5   2010    3129
Total:       1004 2081 716.9   2011    3133

Percentage of the requests served within a certain time (ms)
  50%   2011
  66%   2121
  75%   2998
  80%   3005
  90%   3013
  95%   3120
  98%   3127
  99%   3133
 100%   3133 (longest request)

Siege is similar:

$ siege -c 200 -r 2 -d 0 --no-parser "http://hp/delay.php"
** SIEGE 4.0.4
** Preparing 200 concurrent users for battle.
The server is now under siege...
Transactions:                400 hits
Availability:             100.00 %
Elapsed time:              10.29 secs
Data transferred:           0.01 MB
Response time:              4.58 secs
Transaction rate:          38.87 trans/sec
Throughput:             0.00 MB/sec
Concurrency:              178.12
Successful transactions:         400
Failed transactions:               0
Longest transaction:            7.27
Shortest transaction:           1.00

Logging, otherwise, records the real delays and latencies for each request. In Apache 2.4.13 and later Logging, there's a logging directive "%^FB", giving elapsed microseconds between when the request arrived and the first byte or backend output. Another option would be to use "%{begin:msec}t %{end:msec}t" in the custom log string.

Yet another source of information is PHP's fpm_get_status()23. A simple use of this information would be:

echo '<pre><?php print_r(fpm_get_status());' > /var/www/html/testfpmstatus.php

$ curl http://localhost/testfpmstatus.php

<pre>Array
(
    [pool] => www
    [process-manager] => dynamic
    [start-time] => 1659800269
    [start-since] => 72
    [accepted-conn] => 2
    [listen-queue] => 0
    [max-listen-queue] => 0
    [listen-queue-len] => 0
    [idle-processes] => 9
    [active-processes] => 1
    [total-processes] => 10
    [max-active-processes] => 1
    [max-children-reached] => 0
    [slow-requests] => 0
    [procs] => Array
        (
            [0] => Array
                (
                    [pid] => 1024097
                    [state] => Idle
                    [start-time] => 1659800269
                    [start-since] => 72
                    [requests] => 1
                    [request-duration] => 479
                    [request-method] => GET
                    [request-uri] => /testfpmstatus.php
                    [query-string] => 
                    [request-length] => 0
                    [user] => -
                    [script] => -
                    [last-request-cpu] => 0
                    [last-request-memory] => 2097152
                )
            [1] => Array

See Also:

• https://stackoverflow.com/questions/16882720/how-to-get-backlog-of-listening-socket ;
• https://code.google.com/archive/p/mod-log-firstbyte/
• https://httpd.apache.org/docs/2.4/mod/mod_logio.html
• real-time-php-fpm-status.md

Answer 3

Short answer: No.

Long answer: It all depends on the application and how much and what kind of processing the application does.

For example:

In application A, a typical request takes 50ms to finish. This means that a single server can process 20 requests a second.

In application B, a typical request takes 200ms to finish. Then a single server can process 5 requests a second.

The only way to determine answers for your questions is to measure them in your environment. There are too many variables to get a result by deduction.

For more information, please look into Can you help me with my capacity planning?