Drupal on HHVM

PHP 7 will be released soon, and Drupal comminuty is beginning to consider reworking Drupal's code in anticipation. It seems like much needs to be changed in Drupal code base, though. Community is hopeful to have the the necessary changes made in time for Drupal 8. PHP 7 promises significant boost in performance for OOP elements, which is desperately needed for Drupal 8. There has been a competition in performance between PHP and it's hack, called... well... Hack.

Hack was initially a hack of PHP created by Facebook. I say 'was' because it seems to be gaining own grounds now as a language. A significant performance boost is reached by compiling Hack's PHP code into machine-friendly byte code using IT compiler (Just In Time compiler), which does not compile the whole site at once, but only compiles pieces of code as it sees necessary. This looks a lot like Java with it's virtual machine. Hack's virtual machine is called HHVM (Hip Hop Vierual Machine).

Who's using HHVM? Well... Facebook, Wikipedia, and WP Engine and Box. At least these. That is qute a good start, and the use cases boast 2x to 4x performance boosts. There are also reasons to believe, that PHP 7 will still be way behind HHVM in productivity. Hack started as a hack of PHP, but it is now developing more and more into an alternative language, that pulls blanket off PHP and onto itself. A real competitor, but still young. But, it is likely now, that even the upcoming version of PHP 7 won't bear Hack and HHVM performance-wise.

What does that all mean to a Drupal developer like myself? I gave in to temptation to try HHVM out with Drupal on top of it. Below are some thoughts on this adventure. Whew, what a long introduction!

1. Installation.

HHVM has a good set of pre-built packages with detailed installation instructions. I installed HHVM using Ubuntu 14.10 (Utopic).

It should be noted, that HHVM does not support i386 architecture. So, if you are running a i386 OS, you are out of luck.

It is recommended to install libgmp-dev and libmemcached-dev, because without them, there can be errors.

2. Configuration.

This is where the troubles may creep in, especially if you are using Nginx. I need node, that HHVM installed well under Apache, it is just Nginx that needed some filing. There were three errors that needed specific configurations, without which HHVM would not work.

First, you need to replace the php-fpm settings in Nginx vhost config. If you start HHVM and you see an error message about the 'clashing configuration', open the specified hhvm.conf and see how cgi gets referenced there. You will need to replace the standard php5-fpm's cgi with this new cgi pass, so that you would have HHVM called by Nginx, rather than the usual php5-fpm. Here is a DigitalOcean article that helps to solve this issue.

Second, there is a bug with locale settings, manifesting itself in a 'Fatal error: unexpected St13runtime_error: locale::facet::_S_create_c_locale name not valid' log error message. This error comes from some missing locale settings that some OSes have (like Ubuntu). There is an easy workaround for that bug.

Third, there is a bug with the HHVM PDO not respecting the MySQL socket path. In my case, I ended up with those users, who could not set the socket address in php.ini, whatever config settings they tried. The only solution that worked was creating a symlink ln -s /var/run/mysqld/mysqld.sock /tmp/mysql.sock which, being placed in temp directory, will get periodically lost when temp files get cleared.

After these three problems were solved, the HHVM worked without problems for me, with both Drupal 7 and Drupal 8.

3. Performance Boost with Drupal.

I ran Drupal 7 with MariaDB and Nginx to test how HHVM infulenced Drupal's performance.

Performance boost from HHVM depends on the amount of performance freed on the PHP level. Let me explain. Website performance is as low as is it's bottleneck. There are three usual bottleneck performance for Drupal web sites: CPU and RAM and MySQL. MySQL bottleneck comes from necessity to read and write large arrays of data inot MySQL database. RAM bottleneck comes from having too much code loaded into memory, and, possibly, loaded files, like images during processing and code files when loaded. CPU bottleneck comes from PHP running code - first, interpreting the script, and then, executing it, performing whatever CPU-taxing functions that the code may have.

From the above paragraph it will be clear to you, that HHVM will only grant one type of boost - namely, for CPU usage. Pre-compiled code takes less time to compile and execute. So, a given page will run a little slower on it's first run, but faster on the following runs. If your page has lots of modules working on it, or if it is using heavy OOP, like Drupal 8, then you can expect significant boost with HHVM.

On the other hand, HHVM will not help you with MySQL bottlenecks, and, for me, it took slightly more memory (additional 30Mb) compared to a non-HHVM setup. 30Mb not being much, we may discard RAM issue at all. From my experience and from multiple benchmarks, it is precisely MySQL that serves Drupal's bottleneck most often. If MySQL is your bottleneck, don't expect serious boost from HHVM.

On PHP CPU performance side, there has been a significant boost for me under HHVM, that has mainly been visible under heavy loads, especially for logged in users, for whom Drupal's caching does not apply. For anonymous users, with Drupal cache turned on, and on singular page loads, HHVM yelded no visible results at all. So, you can say, it's best for wen sites that do heavey PHP processing and have lots of people signed in, like Drupal forums and social platforms.



  1. HHVM is a powerfool platform, that can speed up loaded and crowded sites full times' count.
  2. HHVM is developed by Facebook, and has good support. It is also used by some IT mosters like Facebook and Wikipedia, and so you can count on it's good continuation.
  3. Latest HHVM Seems to work well with both Drupal 7 and Drupal 8.
  4. HHVM works well with Apache and Nginx, later needing some manual configuration.


  1. HHVM is not precisely PHP, it is diverging. Drupal seemd to run well under HHVM, but there is a constant feeling that some divergence may surface up. There is no guarantee, that the future versions of Drupal will work with the future versions of HHVM well.
  2. HHVM can be hard to set up and configure if you are not very technical.
  3. HHVM will save your day on sites with high PHP processing, but it will not help you with heavy MySQL usage. Use MariaDB or Percona to level this up some.

Overall, it seems to me, that the server of Linux, Nginx, HHVM and MariaDB is a very worthy beast, that can take your site farther than most. I really considered switching my website AlexRayu.com to this setup. But I have decided not to. Why? Because my web site is not really loaded at any time, and Nginx + MariaDB seem to be performing quite well on my Digitalocean 512Mb instance.

If this article has been helpful, if you agree or disagree, feel free to comment below.