原文链接：http://forumone.com/insights/running-drupal-on-hhvm/

去年三月，Facebook发布了HACK，一个服务于HipHop虚拟机(简称HHVM)，且号称可以无缝地与PHP语言交互操作的开源编程语言。看到这个消息后，我就被深深吸引了，我一直在关注他们为提高与PHP交互的性能而做的所有努力。我产生了一个想法：虽然我们没有像Facebook那样直面开发过程中的挑战，但是我们可以尝试在最新的HHVM版本环境下运行Drupal，看看会发生什么。

官方的HHVM包只分布在Ubuntu和Debian上，幸运的是有好心人已经为CentOS打包了。所以我们快速的部署好虚拟机和一些额外的包之后，就可以开始测试了。我们选择了去年开发的一个相当复杂的站点来做测试，这个站点大量使用了Panels和Display Suite，并且内容之间关联很多。这意味着，几乎所有页面，drupal都会加载数个实体对象。

我在本地虚拟机搭建了这个站点的运行环境，配置是4核，分配了65G的内存。然后还做了一些其它的性能优化方案，接着就以HHVM环境和PHP-FMP环境做对比，我们随机抓取了1000个页面地址，使用JMeter来模拟了30个并发。

我们记录了运行时间和服务器的负载情况。

PHP-FPM

冷启动站点后，我们清除了Drupal的缓存，重启了Nginx，PHP-FPM和MySQL。然后我们点击了站点首页来永久缓存一些内容条目，随着请求的增加，完成每次请求的时间像预想中的一样，也随着增加了：

                                                 每5秒采样的平均相应时间，冷启动

服务器上的现象也证明了这些数据：

                                                   CPU和内存的使用情况，冷启动

下面是专门监测mysqld的cpu和内存使用情况：

                                                 mysqld的CPU使用情况，冷启动

                                                 mysql的内存使用情况，冷启动

MySQL的CPU占有率一直在40%-60%之间，只有少数情况达到了单核的100%。其它的核完全被PHP-FPM使用。同样地，MySQL的内存使用量也是一直维持在300M。我不太确定是什么导致了那些内存使用峰值，这些峰值一直会断续出现，我猜是发生了I/O的阻塞情况导致的，可能是来自MySQL或者Nginx。

第二次测试，我们改为持续访问一个相同的页面来测试。总体来说，它降低了大约400毫秒的中值响应时间，提高了足足2081个页面/每分钟的吞吐量。平均的响应时间相对上一次测试来说有更多的起伏，但最后结果还是很一致的。 

                                              每5秒抽样的平均响应时间，暖启动

                                         整体CPU和内存的使用情况，暖启动

HHVM

接下来换HHVM上场，当然我们要把PHP-FPM禁用，跟之前的测试准备一样，重启虚拟机，清除Drupal缓存，重启Nginx，访问首页，使用JMeter来模拟测试。

                                         每5秒采样的平均相应时间，冷启动

首先我们注意到的现象就是时间花费只有之前测试的一半，图表的每一部分的结果都更好，峰值和谷值的数字都更低。图表最开始不协调的地方，那是即时编译器在运行。

下面看服务器的统计，看来他们也表现的更好：

                                           整体CPU和内存的使用统计，冷启动

HHVM运行时有一个单独的进程，所以我们也能获取到它的CPU和内存使用情况：

                                           mysqld和HHVM的CPU使用统计，冷启动

                                          mysqld和HHVM的内存使用统计，冷启动

一看这些图表，我们就能很明显的发现一些事情。也就是说，对于CPU和内存的使用，HHVM表现的比PHP-FPM要好。HHVM的最高内存使用峰值只有320M，只占整个系统内存使用的20%，而PHP-FPM的百分比是25-26%。CPUT的内存使用率，最高点时，HHVM占整个系统使用的90%左右，平均占有率60%，而PHP-FMP峰值达到95%，平均占有率70-75%。

与测试PHP-FPM时相同，我们使用相同的情境再对HHVM的暖启动进行测试。结果与PHP-FPM一样，只有微小的差别，中值响应时间大概有200毫秒的差别。

分析

如果我们只看最高水平，HHVM相对PHP-FPM来说表现更好。

 

我们看到了吞吐量有两倍以上的差别，响应时间也相差了一半多，相比较各自对系统资源的消耗而言，非常有力的证明我们改用HHVM是非常明智的。

然而我们还有一些重要的事项需特别注意，最重要的一点是尽管HHVM团队非常努力的想要与Zend PHP的进展保持一致，但是始终会慢半拍。最近的一次报告显示，对于Drupal运行在HHVM环境上的测试，通过了99.83%，但是天知道还会有什么奇怪的第三方模块会影响到它。举个例子，我们就不能让GD库工作起来，尽管从各方面看起来它没有理由不工作...不过还好我们可以用ImageMagic替代它。虽然我们对HHVM进行测试的页面都没有出现访问问题，但不保证实际使用环境中都能正常访问。我们测试的页面都是前台的页面，而有些后台管理页面是行不通的。有一些PHP模块已经被加入支持了，比如APC和memcache，也有第三方的团队在增加别的支持，比如MongoDB, Ice和Redis，但是也有很多模块没有，或者永远不会被支持。 

而且这个计划也有不稳定因素。虽然目前HHVM团队计划每8周发布一个版本更新，想必他们不会在功能上做重大的回归，但我们不敢确定。

类似地，现在他们只对Ubuntu和Debian提供官方的包，所以如果你是运行在Fedora或者CentOS上的话，你得从源上或者第三方组织的库里获取，而且他们可能不会及时更新。

免责声明

以上性能测试结果，只是在一个MacBook Pro（2.3 GHz 酷睿i7处理器）上安装的非生产环境的虚拟机上，运行一个正式站点环境的结果。加载测试是由另外一台机器通过无线网络产生的，这台机器并没有用作其它用途。加载测试并没有包含等待时间和非PHP资源的访问，也并没有伪装成真实的用例，只是为了检查下php解释器的性能