Over the past week, we’ve looked at multiple methods to run PHP on Apache. By default, it runs as an Apache module with all the related efficiencies and security challenges. The most important reason to switch off the Apache module is so that scripts are run using the owner of the folder and files. Otherwise, in a virtual hosting environment with multiple users sharing the same server, it can be possible for one user to modify the PHP scripts of another, and run them.
So far, we’ve covered three different approaches to run PHP on Apache:
- Without any changes – using the default Apache module;
- Using suPHP to take care of the above security issues;
- Using FastCGI via PHP-FPM.
All three installations have their advantages and disadvantages. However, in this article, I’m going to look at performance implications for all three. Conventional wisdom says that the default configuration with PHP run as an Apache module via mod_php is the fastest implementation and that suPHP is the slowest. Let’s put that to the test.
Generating a “Stress Test” Script
There are many different ways to stress test a PHP script. Do we look at the speed of the PHP execution itself? The number of pages it can generate? In this article, we’ll look at the pure speed at which PHP operates via running through 100 million iterations of a loop.
The script is a simple one. I’ve used this sample from Github as a basis. It only measures how long the script takes to run a “for” loop. After running it multiple times on each of the three implementations of PHP, here are the results.
Results for PHP Performance FastCGI vs. suPHP vs. Apache Module
Slowest – suPHP
suPHP is known to be one of the slowest implementations of PHP. This is because it spins off a new binary for every request. Here’s the output from the test script:’
Running the test multiple times returned the same range of execution times. At 6.5 seconds, it’s the most inefficient of the three.
Second Place is the Apache Module
I was expecting the default mod_php to be the fastest of the three, but it consistently came out with the same results even after running it multiple times. Here’s the screenshot:
You can see that it’s a good bit faster than suPHP. Since PHP runs as an Apache module, it doesn’t have to spin off a new process for each request.
Quickest – FastCGI
FastCGI lived up to its name. It’s a much quicker implementation of the CGI engine. Like suPHP, it can also shore up security by running scripts with the name of the owners, rather than “nobody” or “apache.” However, unlike suPHP, it doesn’t need to start up a new process for every request. Instead, it operates out of “pools” of users and uses the same pools for different users. Here’s the output for FastCGI:
In the screenshot, it might not seem like too much of a difference between FastCGI and mod_php, but execution times were as low as 4.6s for FastCGI. So It has a bit more speed. But in general, FastCGI and mod_php seem to be pretty comparable as far as demands on the CPU go. Specifically, the PHP-FPM implementation of FastCGI that deals specifically with PHP, has quickly become very common. And looking at the speeds at which it can run, it’s easy to see why.
So these are my results. They were comparing the execution times of scripts using FastCGI, suPHP, and mod_php (Apache module). FastCGI comes in first, the Apache module barely behind, followed by suPHP which is by far the slowest.