PHP 7 vs HHVM (WordPress)中文EN

I've actually said this on many occasions already: PHP 7's performance is now on par with HHVM..
And yet, people keep asking...
Also, Weibo doesn't feel like a great place for this to be preserved over time, so I'm writing a blog post about it.
In this post I'll run the most objective comparison I can: just hammer WordPress's front page with ab..
and compare the performance of PHP 7 and HHVM-3.2.0 on WordPress.

Machine spec:

CPU: 4 X Intel(R) Xeon(R) CPU           E5410  @ 2.33GHz
Mem: 16G

Environment:

Nginx + PHP-FPM
Nginx + HHVM

Software versions:

PHP7 - 79354ba6d0d6a1a4596f9ac66ee9bc3a34ed972b
HHVM-3.2.0

HHVM's configuration:

$ cat /etc/hhvm/server.ini
; php options
pid = /var/run/hhvm/pid
; hhvm specific
hhvm.server.host = 127.0.0.1
hhvm.server.port = 9000
hhvm.server.type = fastcgi
;hhvm.server.file_socket = /var/run/hhvm/hhvm.sock
hhvm.server.default_document = index.php
hhvm.log.level = Error
hhvm.log.always_log_unhandled_exceptions = true
hhvm.log.runtime_error_reporting_level = 8191
hhvm.log.use_log_file = true
hhvm.log.file = /var/run/hhvm/error.log
hhvm.repo.central.path = /var/run/hhvm/hhvm.hhbc
hhvm.mysql.typed_results = false

PHP's configuration (pm.max_children matched to your CPU core count):

php-fpm.conf:
pm = static
pm.max_children = 4
php.ini (opcache):
zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.save_comments=0
opcache.fast_shutdown=1
opcache.enable_file_override=1

To make the objectivity of the test visible, I decided to screen-record it — I recorded the whole process while running the tests. Feel free to watch along..
Video:

The results are as follows (both tests first warm up with 100 requests, then run ab with 100 concurrent connections and 10,000 requests):
PHP7:

Concurrency Level:      100
Time taken for tests:   38.726 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      89290000 bytes
HTML transferred:       86900000 bytes
Requests per second:    258.22 [#/sec] (mean)
Time per request:       387.260 [ms] (mean)
Time per request:       3.873 [ms] (mean, across all concurrent requests)
Transfer rate:          2251.64 [Kbytes/sec] received

HHVM-3.2

Document Path:          /wordpress/
Document Length:        8690 bytes
Concurrency Level:      100
Time taken for tests:   43.296 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      89260000 bytes
HTML transferred:       86900000 bytes
Requests per second:    230.97 [#/sec] (mean)
Time per request:       432.957 [ms] (mean)
Time per request:       4.330 [ms] (mean, across all concurrent requests)
Transfer rate:          2013.31 [Kbytes/sec] received

Conclusion:
PHP7 - 258.22 QPS
HHVM - 230.97 QPS
PHP 7's performance in a real-world scenario is indeed already on par with HHVM, and in some scenarios it even beats HHVM (PS: I wanted to test against HHVM-3.3, but my Ubuntu 13.10 simply wouldn't compile it, so I tested with 3.2 — the difference between them isn't large anyway).
Finally, PHP 7 will have its official release in October of next year. I believe we'll make it faster still, so stay tuned 🙂
PS: There's one more reason I'm publishing this. A certain company put out a series of articles about their migration to HHVM. One passage went like this: they found that their workload showed no big performance difference between PHP 5.5 (note: not even 7) and HHVM, so after optimizing separately for HHVM and for PHP 5.5, they compared again and arrived at a "general conclusion."
So here's the problem: that's equivalent to writing one feature in HHVM and then writing another feature in PHP. The two codebases aren't identical, the logic isn't identical — can you really draw a "general conclusion" from that comparison?
Because how much optimization you did for PHP, and how well you did it, is very hard to assess. Someone else doing the optimization might reach the exact opposite conclusion (for instance, we also did some optimization on top of PHP 5.4 and made Weibo's mobile server-side performance 2.6x faster while cutting servers by 60% — how would you explain that? Optimization overview: 微博LAMP性能优化之路)?
That article also had this line: "hhvm is based on the PHP 5.4 syntax standard, so hhvm and php5.5 both differ syntactically from the php5.2 we currently use, with php5.5 differing more."
You call that a "difference"? 5.5 versus 5.2 is 99% compatible... You lump HHVM's incompatibilities together with PHP 5.5's new syntax and call them both "differences"? Are those the same thing?