The PHP-FPM is an entire rabbit hole in itself, so feel free to explore if you wish, but for our purposes, this much explanation will do. 🙂
Why optimize PHP-fpm?
So why worry about all this dance when things are working all right? Why not just leave things as they are.
Ironically, that is precisely the advice I give for most use cases. If your setup is working fine and doesn’t have extraordinary use cases, use the defaults. However, if you’re looking to scale beyond a single machine, then squeezing out the max from one is essential as it can cut down the server bills in half (or even more!).
Another thing to realize is that Nginx was built for handling huge workloads. It’s capable of handling thousands of connection at the same time, but if the same isn’t true of your PHP setup, you’re just going to waste resources as Nginx will have to wait for PHP to finish with the current process and accept the next, conclusively negative any advantages that Nginx was built to provide!
So, with that out of the way, let’s look at what exactly we’d change when trying to optimize php-fpm.
How to optimize PHP-FPM?
The configuration file location for php-fpm may differ on the server, so you’ll need to do some research for locating it. You can use find command if on UNIX. On my Ubuntu, the path is /etc/php/7.2/fpm/php-fpm.conf. The 7.2 is, of course, the version of PHP that I’m running.
Here’s what the first few lines of this file look like:
;;;;;;;;;;;;;;;;;;;;; ; FPM Configuration ; ;;;;;;;;;;;;;;;;;;;;; ; All relative paths in this configuration file are relative to PHP's install ; prefix (/usr). This prefix can be dynamically changed by using the ; '-p' argument from the command line. ;;;;;;;;;;;;;;;;;; ; Global Options ; ;;;;;;;;;;;;;;;;;; [global] ; Pid file ; Note: the default prefix is /var ; Default Value: none pid = /run/php/php7.2-fpm.pid ; Error log file ; If it's set to "syslog", log is sent to syslogd instead of being written ; into a local file. ; Note: the default prefix is /var ; Default Value: log/php-fpm.log error_log = /var/log/php7.2-fpm.log
A few things should be immediately obvious: the line pid = /run/php/php7.2-fpm.pid tells us which file contains the process id of the php-fpm process.
We also see that /var/log/php7.2-fpm.log is where php-fpm is going to store its logs.
Inside this file, add three more variables like this:
emergency_restart_threshold 10 emergency_restart_interval 1m process_control_timeout 10s
The first two settings are cautionary and are telling the php-fpm process that if ten child processes fail within a minute, the main php-fpm process should restart itself.
This might not sound robust, but PHP is a short-lived process that does leak memory, so restarting the main process in cases of high failure can solve a lot of problems.
The third option, process_control_timeout, tells the child processes to wait for this much time before executing the signal received from the parent process. This is useful in cases where the child processes are in the middle of something when the parent processes send a KILL signal, for example. With ten seconds on hand, they’ll have a better chance of finishing their tasks and exiting gracefully.
Surprisingly, this isn’t the meat of php-fpm configuration! That’s because for serving web requests, the php-fpm creates a new pool of processes, which will have a separate configuration. In my case, the pool name turned out to be www and the file I wanted to edit was /etc/php/7.2/fpm/pool.d/www.conf.
Let’s see what this file starts like:
; Start a new pool named 'www'.
; the variable $pool can be used in any directive and will be replaced by the
; pool name ('www' here)
[www]; Per pool prefix
; It only applies on the following directives:
; - 'access.log'
; - 'slowlog'
; - 'listen' (unixsocket)
; - 'chroot'
; - 'chdir'
; - 'php_values'
; - 'php_admin_values'
; When not set, the global prefix (or /usr) applies instead.
; Note: This directive can also be relative to the global prefix.
; Default Value: none
;prefix = /path/to/pools/$pool
