HHVM in one sentence is a relatively new implementation for the PHP runtime, built by Facebook as open source project and focused on improving PHP performance.
For about half a year (somewhere around late 2014) Wordpress is fully supported by the HHVM runtime.
There are plenty of posts around the net claiming you can get a boost of 5 times faster page loading times (reduction of 80% of the original response times) and up to 40 times faster page loading times (reduction of 97.5% of the original loading times) by simply switching from the original PHP runtime to HHVM.
As I'm in the seek to improve overall response times for our new Wordpress based platform, such improvement figures sounds like I must give it a try.
I've created a new application server into our load testing environment, installed it by following installation guidelines from Building-and-installing-HHVM-on-RHEL-7, made few tweaks and got it to work with Apache via FastCGI.
With that I've started to manually browse across the Wordpress system and feel if there's any improvement to performance. Using Chrome developer tools I've noticed a decrease with page response times from around 400ms to 300ms for viewing different blog posts. Meaning a 1.5X times improvement (or reduction of 25% of the original response times).
After validating that the Wordpress application works fine and resolved several issues, I've decided it is time to start load testing the cluster.
At that point - I had a cluster of 3 "normal" PHP app servers (php 5.5 with opcache enabled) and 1 HHVM-based app server, all in the same network, having the same sizing, connected to the same DB, having the same application installed with as close as possible configuration.
Starting the load test while monitoring application response times and comparing between the 3 normal PHP-based app servers and 1 HHVM-based app server (shown as app08 below).
Here are some figures for few Wordpress activities I've been looking into:
At this point we decided not to use HHVM yet, as we are so close to the initial go-live and using HHVM will also force us doing some infrastructure changes to comply with the HHVM prerequisites, but at least we know what is it that we are missing.
For about half a year (somewhere around late 2014) Wordpress is fully supported by the HHVM runtime.
There are plenty of posts around the net claiming you can get a boost of 5 times faster page loading times (reduction of 80% of the original response times) and up to 40 times faster page loading times (reduction of 97.5% of the original loading times) by simply switching from the original PHP runtime to HHVM.
As I'm in the seek to improve overall response times for our new Wordpress based platform, such improvement figures sounds like I must give it a try.
I've created a new application server into our load testing environment, installed it by following installation guidelines from Building-and-installing-HHVM-on-RHEL-7, made few tweaks and got it to work with Apache via FastCGI.
With that I've started to manually browse across the Wordpress system and feel if there's any improvement to performance. Using Chrome developer tools I've noticed a decrease with page response times from around 400ms to 300ms for viewing different blog posts. Meaning a 1.5X times improvement (or reduction of 25% of the original response times).
After validating that the Wordpress application works fine and resolved several issues, I've decided it is time to start load testing the cluster.
At that point - I had a cluster of 3 "normal" PHP app servers (php 5.5 with opcache enabled) and 1 HHVM-based app server, all in the same network, having the same sizing, connected to the same DB, having the same application installed with as close as possible configuration.
Here are some figures for few Wordpress activities I've been looking into:
If you've been reading my blogs for a while, you would know that my load tests are basically hitting the system with production-like workloads, meaning that the entire setup is not under stress and doesn't suffer from any resource starvation, but rather is kept pretty idle, not using more than 20-30% of CPU across the different components (app/db servers).
What is fairly easy to see here is that also with load test running, the performance is a lot like what I saw with my manual, single user browsing around the system.
Here is a summary:
- Viewing a blog post improved from 475ms to 300ms (37% reduction / 1.6X times faster).
- Viewing the homepage improved from 850ms to 600ms (30% reduction / 1.4X times faster).
- Login improved from ~350ms to ~220ms (37% reduction / 1.6X times faster).
- Posting a comment degraded from 500ms to 5500ms (-1000% reduction / 10X times slower).
I've decided to ignore this for now, as it was only evaluation of HHVM.
Not sure what was the cause for this decrease in performance.
Basically HHVM was tested as is, without any other optimization or configuration changes.
I found that the version I used was already with JIT enabled and with the defaults to JIT code after few executions (cannot recall but I think it was 10 or 12 runs).
Looking back to the original numbers which led me to give that a try, this was somewhat disappointing. I've been looking to give a try with HHVM precompiling but I'm not sure I got it right or just didn't see any significant improvements. Maybe that's obsolete? Anyone knows?
At this point we decided not to use HHVM yet, as we are so close to the initial go-live and using HHVM will also force us doing some infrastructure changes to comply with the HHVM prerequisites, but at least we know what is it that we are missing.
