Recently, we did some performance benchmark tests to review the effects of a number of recent (and not-so-recent) optimizations we've made to our hosting platform, particularly for websites powered by WordPress and other PHP-based applications. Accumulated, we expected these improvements to reduce loading times quite a bit, and we weren't disappointed by the results of our tests.
There is a number of factors that can affect the time it takes for a server to process an HTTP request. One of these factors is network latency. Even though our servers have world-class connectivity, the worldwide network routes are beyond our control, so we are not going to focus on that here.
Another is the way scripts and applications process requests. Historically, using CGI (Common Gateway Interface) was the easiest and most reliable way to run PHP scripts. For applications like WordPress, however, CGI has a large performance hit. It comes from the fact that the server starts a brand new PHP process to handle each request.
This is not a big deal if a website only receives a small number of requests to process. For example, if the site is not visited frequently, the performance hit from using CGI can be negligible, and the reliability and ease of use of CGI may outweigh the downsides.
For busy websites, however, CGI performance gets progressively worse the higher the number of requests becomes. A lot of the time, the server is busy just spinning up new instances of PHP over and over again, and at some point the time it takes to create new PHP processes exceeds the time needed to actually process them. In general, creating new processes is expensive in terms of server resources, and using a separate process for each request quickly becomes a waste of resources. CGI is simply not performant enough because of that, and FastCGI was developed to address this issue.
With FastCGI, we can use a long-running PHP process to handle a lot of requests during the lifetime of the process. Doing so means we do not waste server resources or, more importantly, time on setting up the environment of the script. Using PHP-FPM, which stands for PHP FastCGI Process Manager, is the default way PHP scripts are processed on our servers.
An additional benefit of using a single process for multiple requests with PHP-FPM is that we can leverage PHP's OPcache mechanism to store the instructions of previously parsed scripts in memory, something that is not possible with short-lived scripts like CGI. Using OPcache further reduces loading times by skipping another time-consuming step in the execution of PHP scripts, parsing the actual PHP code.
Loading Time Tests
The performance tests we did measured the time to first byte (TTFB) to a website based on WordPress.
The network latency for our tests was consistent at about 4 milliseconds. This is very fast and stable compared to the vast majority of websites you can reach on the Internet. Most of the time, latency will be higher and more erratic depending on the location of the server relative to yours, as well as the quality of the network connection between your locations.
Still, we used the closest data center location we have available in order to reduce the effect of the network on the benchmark to a minimum and measure the actual server performance.
There are multiple ways we can go about testing TTFB. In this case, we performed several tests with different tools in order to gather as much data as possible and make our test results more reliable.
The simplest way is using a shell script to make requests to two PHP scripts on the server we tested: one that simply does
exit(), and a working WordPress installation powering a functional website. For this test, we measured TTFB over 10,000 HTTP requests. We also used the ab benchmarking tool bundled with the Apache web server and a couple of other special tools to confirm our results.
The results show that FPM brings significant performance increases across the board. Here is a chart showing the distribution of TTFB across 10,000 HTTP requests:
Note that the Y axis of this chart is logarithmic. This means that lower values seem much bigger than they actually are.
Here is what the chart looks like with a linear Y axis:
You can see that TTFB is quite consistent for FPM, and not so much for CGI. PHP-FPM is also much faster. This is caused by the fact that it is expensive for the server to create new processes and it takes time for all scheduled requests to be handled. Processes that are already running, in contrast, can go about their business without paying much attention to this fact.
All tests were done on a production server, so it was also handling the requests for all other websites hosted on it at the same time. This makes the data we gathered very representative of the performance you can expect from your hosting account with us.
According to the WPPerformanceTester plugin, WordPress performance on our servers is several times better than industry average:
You should also have in mind that the Server-Side Cache feature on our servers was not used when these tests were performed. We did not use it in order to measure the actual performance boost coming from PHP-FPM, but for production websites based on WordPress, we recommend using the Server-Side Cache feature to improve loading times even further.
The performance increase for PHP sites using FPM is close to tenfold. This is the main reason that FPM has become the default PHP handler on our hosting servers. Coupled with our powerful hardware and excellent connectivity, this brings top of the line performance for all websites hosted on ICDSoft servers.
There are a few limited cases in which CGI can be useful, so the option to run PHP scripts this way on our servers remains.
Since PHP-FPM was introduced as a technology on our servers last year, there are still websites on our servers that run on CGI (we refrain from modifying user content and settings). If your site is still one of them, there is a setting on the PHP Settings page of the Control Panel that controls whether the site runs on CGI or PHP-FPM. We highly recommend that you change it to PHP-FPM in order to significantly boost the performance of your website.