PHP-FPM: The Future of PHP Handling

InMotion Hosting’s WordPress Hosting platform uses PHP-FastCGI Process Manager (PHP-FPM) to provide the best performance for websites using the WordPress content management system (CMS). PHP-FPM is an advanced, highly-efficient processor for the PHP scripting language. WordPress websites configured to use PHP-FPM can handle higher amounts of website traffic while using fewer server resources than other PHP handlers. This owes to PHP-FPM’s architecture and features.

For an overview of InMotion Hosting’s WordPress Hosting platform and how PHP-FPM fits into it, please refer to our guide discussing the technologies used in the WordPress Hosting Stack.

• PHP-FPM’s Architecture
• Performance
• Security
• Stability
• Configurability

PHP-FPM’s Architecture

As a high-level programming language, PHP scripts require compiling before a web server’s underlying processor hardware can understand it. Traditionally, the web server handles compiling PHP scripts through integrated web server modules such as single user PHP (suPHP), Common Gateway Interface (CGI), or Dynamic Shared Object (DSO, also known as mod_php). When using these PHP handlers, the web server tightly couples to processing PHP scripts. The server compiles and executes the PHP scripts as part of the individual web server’s processes as it responds to website traffic. They execute using the web server processes’ permissions and ownership configurations. Running PHP this way provides a stable, mature means of using PHP scripts. However, PHP-FPM provides a new experience that addresses many of the shortcomings of the previously mentioned PHP handlers (suPHP, CGI, and DSO).

When using PHP-FPM, a separate service specifically designed for processing PHP scripts handles the task. Internally, PHP-FPM is organized as a “master process” managing pools of individual “worker processes.” When the web server has a request for a PHP script, the web server uses a proxy, FastCGI connection to forward the request to the PHP-FPM service. The PHP-FPM service can listen for these requests on the host server’s network ports or through Unix sockets. Although requests pass via a proxy connection, the PHP-FPM service must run on the same server as the web server. Notably, the proxy connection for PHP-FPM is not the same as a traditional proxy connection. As PHP-FPM receives a proxied connection, a free PHP-FPM worker accepts the web server’s request. PHP-FPM then compiles and executes the PHP script, sending the output back to the web server. Once a PHP-FPM worker finishes handling a request, the system releases the worker and waits for new requests.

The PHP-FPM master process dynamically creates and terminates worker processes — within configurable limits — as traffic to PHP scripts increases and decreases. The extra worker processes it spawns to handle increases in traffic terminate only after a set amount of time has passed, allowing the worker processes to remain available while increased traffic persists. Worker processes also periodically terminate and respawn after serving a fixed number of requests. This helps to prevent memory leaks during the processing of PHP scripts. Each PHP user can have its own separate pool of worker processes for handling PHP requests. Although this does increase some of the overhead of using PHP-FPM, the additional resource cost is negligible and well-offset by its other benefits.

PHP-FPM’s architecture shares design similarities with event-driven web servers such as the NGINX web server and the Apache web server with the Event Multi-Processing Module. Processing PHP scripts in this way allows for much higher processing performance, improved security, better stability, and greater configurability.

Performance

The primary performance benefits of using PHP-FPM are more efficient PHP handling and the ability to use opcode caching for PHP scripts.

As mentioned, PHP-FPM’s event-driven framework allows PHP scripts to use as much of the server’s available resources as necessary without the additional overhead that comes from running them inside of web server processes. PHP-FPM can reuse worker processes repeatedly instead of having to create and terminate them for every single PHP request. Although the cost of starting and terminating a new web server process for each request is relatively small, the overall expense quickly increases as the web server begins to handle increasing amounts of traffic. PHP-FPM can serve more traffic than traditional PHP handlers while creating greater resource efficiency.

The largest performance improvement resulting from using PHP-FPM comes from enabling opcode caching for PHP scripts. When using opcode caching, the resulting opcode from compiled PHP scripts gets cached in memory (RAM). If a request comes in for a PHP script, PHP-FPM quickly checks for previously cached copies of the script. When it finds a cached copy, PHP-FPM executes the script using the cached opcode immediately and continues processing the request.

This ability to immediately execute the opcode from memory removes the need for reading the script’s source code from disk and compiling the PHP source code to opcode. Reading data from the server’s memory is orders of magnitude quicker than reading the same data from the server’s filesystem. PHP-FPM also saves time and resources by not having to compile the PHP source code to opcode. As with starting and terminating processes, the cost and time to read a source code file and compile it may be relatively small on its own but grows with additional instances. For example, when a system repeats those steps tens, hundreds, or even thousands of times a second, the aggregate cost can significantly impact the resource usage of a web server. Using opcode caching significantly improves the efficiency of processing PHP scripts, especially when processing large volumes of requests for PHP scripts.

Security

Enabling opcode caching while still maintaining isolated PHP processing for each user allows PHP-FPM to offer enormous security benefits over other PHP handlers. Opcode caching has no effect when using the suPHP and CGI handlers due to the way these handlers manage their memory usage. The DSO handler supports opcode caching, but the DSO module requires running PHP scripts as the Apache user, which can create a security risk. Using DSO may also require additional configuration to ensure that PHP scripts have the proper permissions to allow the Apache user to read them. There are solutions for this problem, but they usually involve installing additional server modules or relying on outdated technologies. By default, PHP-FPM provides opcode caching and isolated PHP script processing.

When using opcode caching, one must take care to configure PHP-FPM for security. For example, the server’s main PHP configuration file should have the following values set to true:

opcache.validate_root = true 
opcache.validate_permission = true

These settings provide an additional layer of restriction that can prevent users from obtaining access to other users’ opcode caches. The main PHP-FPM configuration files contain the necessary settings for providing secure use of PHP-FPM. These concerns apply primarily to multi-tenant hosting environments. For example, InMotion Hosting’s WordPress Hosting platform provides a multi-tenant hosting environment configured to provide a secure platform with PHP-FPM.

Stability

PHP-FPM’s architecture prevents PHP processing from overwhelming a server. When web servers handle requests for PHP scripts in their own processes, additional web server processes have to be created. As traffic for PHP scripts increases, web servers can quickly become overwhelmed, even to the point where the host server becomes unresponsive.

PHP-FPM can only serve as much traffic as it has worker processes to handle. When properly configured, this creates a relatively hard limit on how many requests for PHP scripts it can process at the same time through PHP-FPM. As PHP-FPM’s worker processes become fully utilized, additional requests for PHP scripts will result in timeouts or gateway errors from PHP-FPM. Instead of using up server resources waiting for a response, the web server will simply return a 503 or 504 HTTP status code. Although site visitors may not want to see 503 or 504 HTTP status codes, this behavior is far better than allowing the hosting server to become entirely unresponsive. Additionally, site owners can create custom 503 status pages to improve the user experience versus a non-descript white error page.

Although PHP-FPM’s architecture provides stability, when improperly configured PHP-FPM can become a bottleneck in processing PHP scripts. Properly configuring PHP-FPM to provide enough workers to process the amount of traffic that the web server can process remains key. Too few workers can result in excessive 503 or 504 HTTP responses, even though the web server is not experiencing high levels of traffic. This problem occurs more frequently with single-tenant servers running PHP-FPM with a single pool of worker processes for all websites, such as a VPS hosting server or a Dedicated server. However, multi-tenant hosting environments with separate pools of worker processes also need to have a properly configured PHP-FPM in order to provide enough workers for each tenant’s web traffic.

Configurability

As a separate service, PHP-FPM provides more configuration options than other PHP handlers. Many of these configuration options can also be defined differently for each website on the server. Some of the options include but are not limited to:

• User for running scripts
• Group for running scripts
• Worker Limits
• PHP-FPM worker creation behavior
• Slow PHP script logging
• Status reports
• Connection settings (e.g. listening on a network port or on Unix socket)
• PHP runtime configuration values

Users can finely tune PHP-FPM to provide superior performance for hosting PHP websites over other PHP handlers lacking such configuration options. Unfortunately, properly configuring PHP-FPM can be relatively complex and involved. Users wishing to do so should consult a skilled systems administrator for configuration assistance should the hosting platform not provide a preconfigured version of PHP-FPM. InMotion Hosting’s own WordPress Hosting platform comes with PHP-FPM preconfigured by systems administration experts to provide the best performance for WordPress users and their visitors while also ensuring a safe and secure hosting environment.