In our previous PHP 7 vs HHVM benchmark, Benchmark Series 2: WordPress, we saw HHVM outperform PHP 7 by 7% on WordPress. That test was performed without any cache involvement to test pure HHVM and PHP 7 performance. In our recent Getting the Best WordPress Performance article, we saw just how much of a difference a page cache can make in regards to WordPress performance.
According to W3Techs’ usage report, WordPress is used by 24.3% of all the websites and holds 58.7% of the content management system market share. As the #1 content management system, we want to see how fast WordPress can be in a real world environment.
To this extent, LiteSpeed Technologies is currently developing our own WordPress cache plugin and are excited to share more information on this project as soon as it is available. In the meantime, a third party page caching solution, WP Super Cache, was used for this round of benchmarks. These benchmarks are not intended as a pure PHP 7 vs HHVM comparison, but a WordPress benchmark.Even though this is the case, the results still provide some interesting figures with respect to PHP 7 and HHVM performance, and as such have been including in this series of benchmarks.
Two cache modes in WP Super Cache were used for this test, “Use mod_rewrite to serve cache files” and “Use PHP to serve cache files”. According to their product description, “mod_rewrite” is the fastest and most recommended way to serve cache files as web servers would rather serve from static files instead of processing the heavier and more expensive WordPress PHP scripts. When using “php_mode”, caching will still be performed, but every request will require the loading of the PHP engine.
Neither WP Super Cache nor W3 Total Cache can use the default Permalink Settings, hence the URL list from the OSS Performance project has to be modified. We chose to use Numeric options which literally change the URL from http://192.168.0.61:8092/?p=123 for example, to http://192.168.0.61:8092/archives/123.
Since there are only 2 cores on our VPS test server, we turned off gzip compression for all web servers to help relieve some pressure on CPU and get a more accurate comparison. We are using LiteSpeed Web Server Enterprise for this test, however, OpenLiteSpeed has almost the same performance as our Enterprise version. This means you can replicate this benchmark on OpenLiteSpeed with similar settings and should get similar results.
PHP Opcode cache has been used for all of our benchmark tests.
Benchmark Server configuration:
Typical VPS Server in an OpenVZ container
Running CentOS 7
2 cores of Intel(R) Xeon(R) CPU E5-1620 @ 3.60GHz
LiteSpeed Enterprise: 4.2.24
PHP 5.6 – 5.6.11 – lsapi mod for LiteSpeed and php-fpm mod for Nginx and Apache
PHP7- Version => 7.0.0-dev, Build Date => July 24 2015 – Git latest version -lsapi mod for LiteSpeed and php-fpm mod for Nginx and Apache
HipHop VM 3.8.0-dev
PHP 7 vs HHVM
Since page caching has been used for this round of tests, it is no longer a good indicator for pure PHP 7 and HHVM performance comparison. However, the results may still be a good indicator for real life situations. At the end of the day, maximum performance for WordPress may be the most important consideration, more so than pure PHP performance itself.
In PHP 7 vs HHVM Benchmark Series 2: WordPress, we saw that HHVM was faster than PHP 7 for a cacheless WordPress setup on OpenLiteSpeed. For this round of tests LiteSpeed Enterprise was used instead. The following is the same test being re-run on WordPress without caching using LiteSpeed Web Server Enterprise. 10 concurrent users with 100 repetitions was simulated.
Now what about performance when a page cache is used?
The results show a very interesting change: PHP 7 is no longer the slower of the two engines, rather, it is now 44% faster than HHVM. Even PHP 56 is proving itself to be faster than HHVM by 13%! Again, this is not solely a PHP 7 vs HHVM comparison, it is comparison of PHP 7 and HHVM with a WP Super Cache + LiteSpeed Web Server Enterprise combination on WordPress.
What about the performance difference on different web servers?
We have already seen that LiteSpeed has the lowest IPC among all of the web servers present in our first benchmark, PHP 7 vs HHVM Benchmark Series 1: Hello World. What about on WordPress without a page cache? We again use siege to simulate 10 concurrent users with 100 repetitions for this scenario.
WordPress is faster on both LiteSpeed and Apache than on Nginx when no page cache is used. We also notice that Apache is running with almost the same performance as LiteSpeed. Why is this the case?
When dealing with heavy PHP scripts, although LiteSpeed has the lowest IPC overhead when compared to other popular web servers, PHP still needs time run. For example, when the PHP engine runs a php script that has a sleep(20) function, no matter how low the IPC overhead, it has to run at least 20 seconds. With conditions such as these, it may appear that all web server solutions have almost the same performance. LiteSpeed running at 125.94 Requests/Sec while Apache is running at 125.47 is a good example of this fact.
If this is the case, does LiteSpeed provide any other advantages? The answer is yes. Even when running WordPress without a page cache, LiteSpeed has far lower server load and resource usage than Apache. We mentioned this very fact earlier when simulation 100 concurrent users with 1000 repetitions, which saw LiteSpeed at 0.82 server load and Apache at 6.29 server load on our 2 core test VPS.
The above figure also shows that Nginx is slower than Apache on WordPress without a page caching solution. Is this really true? Popular belief is that Nginx is both more lightweight and faster than Apache. What could have happened here?
While the benchmark result is true, most real world situations will be far more complicated than in the above scenario. Let’s take a look at what would happen if we bring things a little closer in line with this by adding a page caching solution.
We used WP Super Cache rewrite_mode for this test with siege simulating 10 concurrent users with 100 repetitions. Also recall that the WordPress list includes three types of URLs: long tail of posts, WP front pages, and RSS feeds. In rewrite_mode, long tail of posts will be served from static files through rewrite rules, while the WP front pages and RSS feed both still go through the PHP engine even though a cache is being used. This can be checked through the curl command on the test server, for example:
curl -i http://localhost:8092/archives/28 | more
you won’t see “X-Powered-By: PHP”
while on the other hand WP front pages and RSS feeds will still go through the PHP engine even if mod_rewrite is being used.
curl -i http://localhost:8092/ | more
curl -i http://localhost:8092/?feed=rss2 | more
Without further ado, let’s see the result:
Nginx is now running 26% faster than Apache with 3703 requests/sec on WordPress when page caching is used. Similarly, LiteSpeed is running 89% faster than Apache and 50% faster than Nginx. Again, this is only a simulated scenario of 10 concurrent users with 100 repetitions. Real world situations may be more complicated. This does however provide some insight into the fact that using different web servers can have a huge impact on WordPress performance.
We have seen that HHVM bests PHP 7 on WordPress without a page cache setup in our previous WordPress benchmark, but that it is definitely not the fastest WordPress setup. After thinking about how to achieve the highest possible WordPress speeds in a simplified real world environment, the best answer we came up with was page caching. With a page caching solution, such as WP Super Cache, WordPress can fly with performance gains of around 5700% when compared to WordPress without caching.
While not to the same degree as caching vs no caching, we also found that your choice of web server can also play a big role in the speed of your WordPress site when using a caching solution. This especially true when experiencing high traffic! As we found out in our Getting the Best WordPress Performance article; LiteSpeed runs even faster in high traffic situations where Apache slows down, and it does so with much lower server load and resource usage!
HHVM is ahead of the game when no caching is used, but both PHP 7 and PHP 56 are faster than HHVM when page caching is used.
Our purpose for this benchmark was to reveal some facts that, if not completely similar to your situation, can at least provide some fundamental figures and information that can be useful in informing you of the different options you might consider taking with your WordPress site in respect to servers and PHP engines.
Last but not least, development on our own WordPress cache plugin is currently underway. After our last project, the successful LiteMage for Magento caching solution, we are expecting big things. How fast will it be in comparison to existing WordPress caching solutions currently on the market? We are waiting to release this information until after we have performed some solid testing. We promised that LiteMage Cache would be 15 to 20 times faster than Varnish-based solutions, and overwhelming feedback has told us that we have delivered on that promise. Our WordPress cache plugin could very well be another big hit. We will just have to wait and see!
What do you think about this test? What would you like to see next? If you have any feedback/comments/recommendations, we are keen to hear from you. Shoot us an email at firstname.lastname@example.org.