PHP-FPM is an alternative PHP FastCGI implementation with some additional features useful for sites of any size, especially busier sites. It runs as its own process
and is not dependent on the web server, like mod_php(default Apache module).

PHP-FPM maintains “pools” (workers available to respond to PHP requests) to accomplish this. It is faster than traditional CGI-based methods, such as SUPHP, for
multi-user PHP environments. It does not overload a system’s memory with PHP from Apache processes

Features of PHP-FPM:

• Adaptive process spawning
• Advanced process management with graceful stop/start
• Ability to start workers with different uid/gid/chroot/environment and different php.ini (replaces safe_mode)
• Stdout & stderr logging
• Emergency restart in case of accidental opcode cache destruction
• Accelerated upload support
• Support for a “slowlog”
• Enhancements to FastCGI, such as fastcgi_finish_request() – a special function to finish request & flush all data while continuing to do something time-consuming  (video converting, stats processing, etc.)

It was not designed with virtual hosting in mind (large amounts of pools) however it can be adapted for any usage model.

Install and configure

PHP now includes the fastCGI process manager (php-fpm) in the stock source code.
Your distribution or OS will either include it in the stock PHP package, or make it available as an add-on package; you can build it from source by adding –enable-fpm
to your ./configure options.

This provides us with a new binary, called php-fpm, and a default configuration file called php-fpm.conf is installed in /etc. The defaults in this file should be okay
to get you started, but be aware that your distribution may have altered it, or changed its location.

Configuration

Inside this configuration file you can create an arbitrary number of fastcgi “pools” which are defined by the IP and port they listen on, just like apache
virtualhosts.

The most important setting in each pool is the TCP socket (IP and port) or unix domain socket (UDS) php-fpm will be listening on to receive fastCGI requests; this is
configured using the listen option.

The default pool, [www], has this configured as listen 127.0.0.1:9000: it will only respond to requests on the local loopback network interface (localhost), on TCP
port 9000. Also of interest are the per-pool user and group options, which allow you to run that specific fpm pool under the given uid and gid.

Pay special attention to the slowlog settings (request_slowlog_timeout and slowlog directives), that is, through this log and a reasonable amount of timeout, you can
easily see which php calls from your application take longer than expected and start debugging them right away.

To start the php-fpm daemon; if your distro uses the provided init script, run

/etc/init.d/php-fpm start

Or if not, start it manually with

php-fpm -y /path/to/php-fpm.conf -c /path/to/custom/php.ini

If you don’t provide php-fpm with its own php.ini file, the global php.ini will be used. Remember this when you want to include more or less extensions than the CLI or
CGI binaries use, or need to alter some other values there.

You can include per-pool php.ini values in the same way you would define these in apache previously for mod_php, using php_[admin_](flag|value).

To see what is being logged specifically by php-fpm set the log path to:
error_log /var/log/php-fpm.log

If you don’t set a php-fpm logfile, errors will be logged as defined in php.ini.

Its working:

It works with the concept of pools, using which we can control the amount of resources dedicated to each virtual host, and also run PHP scripts as different
users.

The major advantage of PHP-FPM is that it relies on the concept of pool management. Each pool of PHP-FPM can be viewed as a full instance of PHP, having a configuration, limit and restrictions of its own. These limitations, restrictions, and configurations are in terms of the child processes, modules, environment
variables, folders, and logs.

Working with Apache:

PHP works with all major web servers and it can be run in different ways on your server. One of the most common known ways to run PHP is the mod_php module. This is
because it comes by default on the Apache HTTP servers. But there is a slight problem. Unlike PHP-FPM, mod_PHP locks out processes and disrupts the performance of a
website.

If your primary goal for hosting your web application with an optimized cloud service is to achieve optimal performance and security, then PHP-FPM is the way forward.

PHP-FPM dramatically speeds up the performance of your PHP environment.
It made our test websites almost 350% faster when it comes to loading times. Plus, it made the site twice as resource efficient as it was with mod_php, one of the newest way to use PHP in conjunction with a web server, is an alternative PHP FastCGI implementation. This module of PHP can be used with any web
server which is compatible with the protocol of FastCGI.

Based on cPanel server:

How does the system create pools?
The system creates a pool when the /var/cpanel/userdata/[user]/[domain].php_fpm.yaml configuration file exists in the domain. This file must use the following lines at
a minimum:

_is_present: 1

You may place any pool values that you wish within this file. The _is_present value is optional, but is required if you do not set any other values in the file.

The system will perform the following steps for you:

The system scans for the /var/cpanel/ApachePHPFPM/system.yaml and /var/cpanel/ApachePHPFPM/system_pool_defaults.yaml files and then generates a system configuration
for each of the PHP versions.

The system searches for the domain’s yaml files.

The system generates a line in the /opt/cpanel/[ea_php_version]/root/etc/php-fpm.d/[domain].conf file for every domain.yaml file.

To direct the requests to the php_fpm daemon with Apache, the system modifies the httpd.conf file with the rebuild_files() script to resemble the following example:

# php — BEGIN cPanel-generated handler, do not edit
<FilesMatch “.(phtml|php[0-9]*)$”>
SetHandler “proxy:unix:/home/cptest3/cptest3_tld.php_fpm.sock|fcgi://cptest3.tld/”
</FilesMatch>
# php — END cPanel-generated handler, do not edit

Working with NGINX:

we can configure Nginx to send PHP requests off to PHP-FPM:

server {
listen 80;

root /var/www/html;

server_name _;

index index.html index.htm index.debian-default.html index.php;

location / {
try_files $uri $uri/ /index.php$is_args$args;
}

location ~ \.php$ {
incude snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.1-fpm.sock;
}
}
Once edits are complete we can test Nginx and reload:

sudo nginx -t
sudo service nginx reload

The above configuration file will search for php files within the /var/www/html directory and send requests to PHP-FPM if a file is requested that ends in the .php
extension.

Drawbacks:

Once you enable PHP-FPM for an account, that becomes it’s handler and thus the default PHP handler you enable for a version of PHP no longer applies to that account. If you’ve enabled PHP-FPM for all accounts, then it doesn’t matter what you configure as the PHP handler for a version of PHP, because the accounts will instead use

PHP-FPM (no matter what’s configured as the handler).

The FastCGI Process Manager (PHP-FPM) was configured in the server to reduce the amount of system resources used by web server. The web server acts as a proxy and passes only files ending with the .php file extension to PHP-FPM. Using PHP-FPM also allows each virtual host to be configured to run PHP code as individual users, similar to the feature provided by SuPHP. But any issue with the PHP-FPM can cause PHP sites to stop working. To pin point that the issue is due to PHP-FPM and to get the sites back to working, we immediately switched the PHP handler to Fast-CGI.

Load the correct configuration file – Each domain has a virtual host file, which needs to be configured with the settings for its custom PHP-FPM pool. If this config
file is not properly detected by the web server or settings are made in different file, it may not work fine.

FPM process manager can either listen to a socket in the server or a TCP port. If the socket doesn’t have adequate permissions or if the port is not accepting
connections, FPM cannot work

The main settings in a virtual host are the ServerName (domain name) and the DocumentRoot (locations for domain files). For PHP-FPM, there is a directive called
‘ProxyPassMatch’, which helps it to act as a reverse proxy to handle web server requests coming to default web server port 80. If any of these directives are wrongly
configured, it can cause PHP sites to stop working

Conclusion

Reliability, Security, Scalability, and Speed. PHP-FPM provides all these along with a lot of customization and performance tuning opportunities.

Click here for the official link for PHP-FPM