摘要：在一个基于Vagrant的本地环境中，可能是某个错误的原因，导致HHVM测试结果很差；在HHVM伙伴们协助下，该原因仍在研究中！然而，在DigitalOcean的一个4GB虚拟机中，HHVM甚至盖过了最新版的PHP-NG的风头！
结论：它们反映出HHVM的功效更佳（在JIT热启动后），虽然出于某些原因，我们不能在所有装备中获取这些结果。
如果你记得我们在几个月前写过一篇文章，那时WordPress.9表明是完全支持HHVM的，当时是那么令我们欢欣鼓舞。最初的基准测试结果显示，HHVM要比驱动着当前所有PHP构建的Zend引擎高级得多。后来，问题就出来了：
HHVM只能以单个用户运行，这意味着（在共享环境中）安全性差了
HHVM在崩溃后不会自动重启，而不幸的是，它至今仍然经常发生
HHVM在启动时使用大量内存，虽然，它和同规模的PHP-FPM比较，单个请求的内存使用量更低
很显然，你不得不根据你的（或者更确切地说是你的站点）的需求采取折中方案，然而这值得吗？切换到HHVM后，你期望获得多少性能改善呢？
在Kinsta，我们真的想要测试所有新技术，并通常会优化这一切来为我们的客户提供最佳的环境。今天，我最终花了点时间来配置测试环境并进行了一些测试来对比两个不同的构建，一个是全新出炉的WordPress安装，另外一个则添加了大量内容的WooCommerce！为了计量脚本的运行时间，我只是简单地添加了
?phptimer_stop(1);?
这一行到footer.php的/body标记前。
这里是配置环境的详情：
DigitalOcean4GB雨滴容器(2CPU核心,4GBRAM)
Ubuntu14.04,MariaDB10
测试站点：已导入演示内容的Munditia主题，WooCommerce2.1.12WordPress.9.1
PHP5.5.9,PHP5.5.15,PHP5.6.0RC2,PHP-NG（-git-6ccd）和HHVM.2.0（版本是PHP5.6.99-hhvm）
没有进一步大费周章，这些就是我的测试结果，数值越低越好，以秒为单位：
DigitalOcean4GB雨滴容器单位是秒，运行10次，越低越好
看起来似乎PHP-NG在它首次运行后就获得了峰值性能！HHVM需要更多几次重载，但是它们的性能貌似差不多！我等不及PHP-NG合并到开发主干了！：）
一分钟命中数，越高越好。
PHP5.5.15禁用OpCache
执行：26hits
可用性：.00%
消耗时间：59.0secs
传输的数据：2.40MB
回应时间：2.47secs
执行率：4.00trans/sec
吞吐量：0.04MB/sec
并发数：9.87
成功的执行：26
失败的执行：0
最长执行：4.44
最短执行：0.48
PHP5.5.15启用OpCache
执行：hits
可用性：.00%
消耗时间：59.55secs
传输的数据：4.48MB
回应时间：1.4secs
执行率：7.41trans/sec
吞吐量：0.08MB/sec
并发数：9.91
成功的执行：
失败的执行：0
最长执行：2.19
最短执行：0.64
PHP5.6RC2禁用OpCache
执行：hits
可用性：.00%
消耗时间：59.87secs
传输的数据：2.10MB
回应时间：2.80secs
执行率：.46trans/sec
吞吐量：0.04MB/sec
并发数：9.68
成功的执行：
失败的执行：0
最长执行：.65
最短执行：0.54
PHP5.6RC2启用OpCache
执行：hits
可用性：.00%
消耗时间：59.0secs
传输的数据：4.18MB
回应时间：1.42secs
执行率：6.98trans/sec
吞吐量：0.07MB/sec
并发数：9.88
成功的执行：
失败的执行：0
最长执行：1.9
最短执行：0.4
HHVM.2.0（版本是PHP5.6.99-hhvm）
执行：hits
可用性：.00%
消耗时间：59.69secs
传输的数据：9.18MB
回应时间：0.62secs
执行率：16.00trans/sec
吞吐量：0.15MB/sec
并发数：9.94
成功的执行：
失败的执行：0
最长执行：0.85
最短执行：0.2
PHP-NG启用OpCache（构建:Jul）
执行：hits
可用性：.00%
消耗时间：59.88secs
传输的数据：8.6MB
回应时间：0.70secs
执行率：14.18trans/sec
吞吐量：0.14MB/sec
并发数：9.94
成功的执行：
失败的执行：0
最长执行：1.06
最短执行：0.1
注意：这里节略了前一次的测试结果（有误），如感兴趣请访问原文查看。
via: