HHVM and Drupal (i.e. Drupal drinks some RedBull)

slashrsm — Mon, 30 Dec 2013 11:27:19 +0000

HHVM and Drupal (i.e. Drupal drinks some RedBull) slashrsm Mon, 30.12.2013 - 12:27

I've been following HHVM (HipHop Virtual machine) for some time now. Project got a bit more of my attention about a year ago, after session at FOSDEM 2013 by Sara Golemon. PHP has been criticized for quite a lot of it's characteristics, performance definitely being one of those. HHVM seemed to be very promising about fixing it and that's why it got my attention in the first place. Immediately after last year's FOSDEM I tried it with Drupal, but my attempt unfortunately failed miserably. HHVM was simply not yet ready for that.

But first a bit of history...

HipHop was initially developed by Facebook (and they are still it's main contributor). Facebook was looking for something that would make their PHP code base perform faster while still retaining benefits that PHP brings (primarily ease of use for developers). Initially they created a compiler (HPHPc) that transformed a PHP script into a C++ program, which was then compiled into a binary. This approach showed dramatic increase in performance, but also had some problems. HPHPc did not fully support PHP language and was not a simple drop-in replacement for "standard" (Zend) PHP.

Facebook decided to deprecate HPHPc, start working on a bit different approach and HHVM was born. HHVM is a Just-in-time compiler (JIT) for PHP. It behaves very similar to standard interpreter when observed from the outside (which means it can be a drop-in replacement for it), but it works quite different internally. It will run a program as an interpreter at the beginning of execution, collect some statistics for optimization and eventually compile it to byte code on the fly. Compiled program will then run much faster than it's interpreted version. It is quite obvious that we get true performance gains with applications that run for a longer period of time (because of initial interpretation phase and on-the-fly compilation). A standard web (Drupal) application, which is deployed to production servers from time to time, is exactly what we're looking for.

Where are we now?

HHVM achieved same level of performance as HPHPc about a year ago and it is currently supporting almost entire PHP 5.4 language. Facebook recently stated that supporting main PHP frameworks/projects became one of their top priorities with HHVM and they started to run unit tests of ~20 projects to get an idea about the level of support. Drupal is one of those projects and there are currently 100% of it's unit tests (not functional AFAIK) passing when running on HHVM. That fact encouraged me to test HHVM and Drupal once again and this time it went much better than a year ago.

I was able to run Drupal, navigate through it structure, add a node, edit it, display it ... To make it short, it looks very promising. I found some problems with files, but initial poking made me think that we're dealing with solvable problems there.

How does it perform?

I was also interested in performance part (no shi** :). I executed 1000 anonymous requests against Drupal's front page (page cache disabled) using this command:

ab -c 50 -n 1000 https://localhost/\?q\=node

I used PHP 5.5.3 (version that ships with Ubuntu 13.10) with zendoptimizer opcode cache enabled and HHVM which I compiled from master (1b389496b4dcb240fffe9a22e9121d4e82348c7f more precisely). I repeated same test three times; PHP 5.5.3, HHVM (cold start) and HHVM (after initial warm-up).

PHP 5.5.3

Requests per second: 103.00 [#/sec] (mean)
Time per request: 485.420 [ms] (mean)
Time per request: 9.708 [ms] (mean, across all concurrent requests)
Transfer rate: 1160.00 [Kbytes/sec] received

HHVM (cold-start)

Requests per second: 183.08 [#/sec] (mean)
Time per request: 273.101 [ms] (mean)
Time per request: 5.462 [ms] (mean, across all concurrent requests)
Transfer rate: 2008.37 [Kbytes/sec] received

HHVM (warmed-up)

Requests per second: 308.31 [#/sec] (mean)
Time per request: 162.173 [ms] (mean)
Time per request: 3.243 [ms] (mean, across all concurrent requests)
Transfer rate: 3382.10 [Kbytes/sec] received

Results are mind-blowing. HHVM is faster than PHP even in it's interpreter phase (which is actually very surprising) and around three times faster after initial warm-up. This improvement is so significant that it would probably result in savings of tens (if not hundreds) of thousands of Euros/dollars in case of a high-traffic enterprise site. Not that Drupal runs any of that sort....

Where do we go next?

HHVM got quite some attention after their posts lately. It was reported that Rasmus Lerdorf (the founder of PHP) publicly supported Facebook's efforts. There were also some other well-known members of PHP community that discussed HHVM and some projects already started with their efforts to officially support HHVM in the future.

How about Drupal? Do we want to be on this wave and start thinking more seriously about this? Who knows how much progress will HHVM achieve by the time Drupal 8 achieves plateau of productivity. Do we want to make sure that D8 runs on HHVM by default? Do we want to check how much effort would take to make D7 run on it? Drupal likes to present itself as a solution for high-end projects and I think that we should at least start discussing this question. High-end projects would benefit the most out of Drupal and HHVM loving each other and that makes me think that there should be some level of interest for pushing this forward.

Want to know more?

HHVM team writes a blog where they post news about it. It's code is hosted on GitHub, where you'll also find more information if you want to build, install or contribute to HHVM. There are also pre-built packages available for most popular GNU/Linux distributions.