PHP Handlers? mod_php? FPM? How do we make sense of the inner workings of PHP outside of our lines of code? We know we can run PHP on the server to build web applications swiftly, but how can we optimize our environment and configurations to reach maximum scale? We know that PHP has its drawbacks for not being asynchronous or event-driven, which is all the more reason to ensure maximum optimization. The impact of your server environment on your PHP application performance can be more than you think you can afford. A careful examination of your PHP ecosystem will help you avoid suffering performance loss in areas you can otherwise solve for easily.
You can deploy PHP, as an ecosystem, in a myriad of settings. As the demands for web application performance and scalability have increased over time, so have the way in which PHP code is invoked, interpreted and handled. This evolution of configuration optimizations allows for greater scale, security, and durability. If you are uncertain about how your environment is setup, it may be time to audit your environment and reconsider old architectural decisions. Optimizing your PHP application for speed and reliability extends beyond just your code; taking advantage of the latest technology in PHP handling may solve many of your pain points that you might have been oblivious to subsisting. We’ll explore the various ways in which PHP can be configured to work with your web server and compare these runtimes from a performance and scalability perspective.
Handlers
Under-the-Hood in every PHP application exists a web server and the PHP interpreter. As HTTP traffic comes in, your web server completes the request by providing either the static data (e.g. images, Javascript, CSS) or dynamic data. The web server will pass the request on to PHP to handle the interpretation of your application code, create the response, and hand it back to the web server, to then deliver it back to the customer. During this process, the interface in which the web server communicates with the PHP runtime is called the PHP Handler.
An easy way to check what handler you are running is to create a dummy file on your server named phpinfo.php and place in the following code:
<?php phpinfo(); ?>
Load that page up in your browser and look for the Server API entry block.
CGI – mod_cgi
mod_cgi is a common option even to this day, mainly in shared hosting environments or (extremely) legacy applications that haven’t upgraded in almost a decade. It is old, outdated, and recommended never to use in any modern PHP environment.
Running PHP code using this method creates a new CGI process outside of the Apache process causing the PHP interpreter to load (and configs read) upon every request. This approach is not necessarily the most efficient nor effective. Arguably, this method is more secure: using suEXEC mod_cgi can keep the execution of PHP code outside of the scope of Apache meaning that faulty or malicious code cannot go outside of the scope of interpretation. This method is popular for shared hosting environments under the same PHP interpreter roof.
Unfortunately, the bad outweighs the good with this method; because of its inefficient, poor performance, and heavy taxation on server resources, it quickly fell out of preference for serious PHP developers. It also does not support PHP Opcode Cache methods, which clearly rules it out for serious high-traffic environments.
suPHP – mod_suphp
Similar to CGI, suPHP (Single User PHP) is an Apache module. You have the advantage of seeing which user is running which process and taxing the CPU. However, similar to CGI, this is inefficient and as your traffic begins to increase you will very quickly push your server to its limits. The benefit of suPHP is essentially the security and is a popular option for hosting multiple PHP applications on a single server because your PHP scripts run as the owning user. Thus, if your application provides an upload form, the uploaded files will be owned by the same owner of the PHP script itself with the necessary permissions intact. This also guarantees no PHP script execution by any user other than the owner.
With suPHP, you will run PHP as a separate process for each request and quickly max out your resources as your traffic begins to spike. Similar to CGI, mod_suphp quickly fell out of favor for high-traffic scenarios. Unfortunately, suPHP soon fell from popularity as it also provided no support for Opcode Cache. Also, considering its last release was in 2013, it might be safe to assume this project no longer supported.
DSO – mod_php
Considered the de facto standard of PHP handlers, mod_php quickly rose to popularity for its speed and scale. You may probably already have mod_php installed; your phpinfo() dump will show Apache 2.0 Handler under the Server API block.
The DSO handler is perhaps one of the oldest and fastest handlers available. The mod_php module integrates PHP as a part of the Apache process itself allowing Apache to interpret the PHP code. Thus, you do not spawn a new PHP process per request, and your overhead is low as PHP preloads as an Apache child process.
One of the greatest advantages of mod_php is that you can now leverage an Opcode cache (e.g. APC), which in turn, will speed up your average response time in extremely significant orders of magnitude. Speaking of APC, if you have not already checked it out, I have another post in which I briefly cover Opcode Cache, and my colleague Rob Bolton has an excellent article covering it in depth.
A disadvantage to mod_php is that all your PHP application files will be owned and executed by the Apache user. This will cause some loss in visibility into which specific users may be impacting server resources. I do not think for the modern PHP application this is a serious issue; you are probably not running multiple websites on a single server but rather powering one giant PHP application across a farm of servers.
FastCGI – mod_fcgid
FastCGI is what its name implies: a fast PHP implementation handler as a CGI module built with performance in mind. FastCGI will not limit you to only one web server (unlike mod_php) and reduces CPU overhead by keeping PHP scripts in memory and not having to invoke a new PHP process on each request. Security is also tight as you have the benefit of executing PHP scripts as the owning user and not as the Apache user.
A major disadvantage to FastCGI is that it is taxing on your memory consumption (although less so than mod_php). By keeping your PHP scripts in memory, you may find that your RAM usage on your server begins to spike. This is a common symptom with in-memory cache mechanisms, including APC and Memcached. However, you’ll need to find the right tradeoff because keeping data in memory also means lowered CPU usage and faster access to that data, thus reducing the overall response time of your requests.
FastCGI is a good modern alternative to suPHP if security is your primary concern within a shared environment without sacrificing speed.
FPM (FastCGI Process Manager) – php-fpm
While technically not a handler per se, php-fpm is coupled with FastCGI for more efficient process management and can
FPM also supports opcode cache and allows for sharing your APC cache among all php-fpm workers. The additional features that php-fpm provides enables high-traffic PHP environments to begin to scale at levels never before imagined. These types of technical advantages allowed for more scale, better utilization of hardware and OS resources, smarter process management, and more concurrency and throughput. PHP applications are also able to scale across multiple servers better. As of PHP 5.3.3, FPM now ships with PHP.
Web Servers
We’ve been talking a lot about handlers, but to reach an optimal
Apache
Being the most common web server in the world, Apache also has its limitations. As user traffic comes in, Apache will spawn a new worker process per request. Both prefork and MPM mode create new processes per client connection, although worker mode can handle more requests while it serves more than one connection per process. Nevertheless, as your traffic begins to increase you’ll notice your memory begin to exhaust as connections utilize RAM and compete for CPU. You’ll find yourself easily maxing out your connection pool if you run a heavy-traffic environment. You can configure Apache to optimize the number of maximum processes and concurrent connections given your hardware resources, but you’ll still find processes competing, and as traffic increases so do your need to scale.
Nginx
Nginx contains an event-driven, non-blocking, and asynchronous architectural model. If Node.js has taught us anything, this design creates the perfect environment conducive to serving multiple requests at the same time. Because it is non-blocking, it can continue to serve additional events (user connections) without having to wait, and because it is asynchronous, it can handle multiple concurrent users at the same time. The beauty of this model has quickly proven Nginx to be the leading contender for handling massive amounts of traffic under the same server setup. With Nginx, you can even cluster your processes to spawn an additional process per core on your machine, thus increasing your ability to handle more requests per server.
Conclusion
Clearly, you have options. Regardless of whether your primary concern is security or speed, you’ll need to consider your architecture deeply before going down the path of building an ecosystem in which to deploy your PHP application. Take into consideration not only your immediate needs but also your future needs in order to remain scalable as your application grows in size and traffic.
In high traffic environments, coupling the event-driven architectural model of Nginx with php-fpm, you’ll be running PHP optimized to handle massive amounts of traffic. There are, of course, further methods of optimizing the code itself to decrease your average response time, but from a hosting perspective you’ll be rest-assured in flying-high with Nginx and php-fpm under your belt.