Today, we are happy to announce FastCGI support for HHVM. FastCGI is a popular protocol for communication between an application server (e.g. running your PHP code) and a webserver. With support for FastCGI, you will be able to run HHVM behind any popular web server (Apache, Nginx, Lighttpd, etc). The webserver is in charge of handling all the intricate details of the HTTP protocol. HHVM is in charge of what it does best, running PHP code blazingly fast.

If you can’t wait to get your hands on the new feature, just jump to the Installation section. If you are curious about how the new feature was baked into HHVM or just want to learn how well it performs, read on.

How it works

FastCGI was designed to solve one crucial problem that plagued its predecessor CGI, namely: performance. The CGI protocol required that a new instance of the application be spawned on every request. Such a trade-off could have been tolerable for small native programs where start-up overhead was negligible. It is however incredibly difficult for a JIT compiler such as HHVM. The HipHop virtual machine keeps track of the code that ran in the past and reuses bytecode output whenever it sees a known file. HHVM also performs just-in-time compilation, i.e. translates snippets of the bytecode into native machine code when they are run frequently. Both of these features require that an instance of HHVM runs in server mode and lives on from request to request. FastCGI protocol enables that. Moreover, FastCGI can be configured to reuse the same connection for serving multiple requests. This involves serving both requests coming one after another and serving multiple requests in parallel. In the latter case data from multiple requests is multiplexed on a single connection.

HHVM FastCGI server uses asynchronous I/O. This means that an I/O thread will never block waiting on a single connection. Instead, system routines such as select() are used to monitor activity on multiple connections at once. When activity is detected (e.g. file descriptor becomes ready for reading or writing), an I/O thread executes the appropriate non-blocking action. This completes a single cycle of the event loop. This approach maximizes CPU use when serving I/O. Consequently, the threads spend only as much time blocked as absolutely necessary. I/O is served using multiple threads. Once the server is under heavy load, there will roughly be one I/O thread per CPU core. The incoming connections are then distributed evenly between the I/O threads using a round robin. As a result, operations on a single connection are always single-threaded and no additional synchronisation is needed.

A separate set of worker threads is used to execute PHP code. All the (partially) decoded requests are put inside a common concurrent queue. In a loop, each worker thread then pops a new request to be served. At this point, all the request headers are ready. For small requests, the request body will also typically be available. When a request is large (e.g. is a file upload), the worker thread might block waiting on more I/O to become available. The payload can be stored to a file in order to keep memory usage low. Once all the request data becomes available, PHP execution may begin. The output produced by a PHP script is buffered and sent to an I/O thread for further handling.


We conducted benchmarks using Nginx. In the first test we ran a Wordpress instance. The second test showcases HHVM performance for computation-intensive tasks. We used a simple php script computing Fibonacci numbers.


The first test was performed using the Wordpress example page. No changes were made to the wordpress deployment besides filling in mandatory database connection fields. Nginx was used as a web server. Apache bench was used for load testing using this command:

ab -c 50 -n 1000 http://localhost/wordpress/wordpress/?p=1


Sadly the results were pretty bad for PHP. Only 23 requests per second seem to indicate that Wordpress is computationally very expensive to run in an interpreter.

Requests per second: 23.17 [#/sec] (mean)
Time per request:    2157.579 [ms] (mean)
Time per request:    43.152 [ms] (mean, across all concurrent requests)
Transfer rate:       275.42 [Kbytes/sec] received


On a cold start, HHVM still performed much better than PHP-FPM; however, there was a clear penalty associated with the initial JITing of PHP files:

Requests per second: 184.71 [#/sec] (mean)
Time per request:    270.689 [ms] (mean)
Time per request:    5.414 [ms] (mean, across all concurrent requests)
Transfer rate:       2194.38 [Kbytes/sec] received

After the initial warm-up the results got noticeably better:

Requests per second: 949.21 [#/sec] (mean)
Time per request:    52.676 [ms] (mean)
Time per request:    1.054 [ms] (mean, across all concurrent requests)
Transfer rate:       11276.46 [Kbytes/sec] received

That’s a surprisingly good result of roughly 40x higher throughput than the default PHP-FPM setting.


Next we decided to compare the two runtimes using a computationally expensive example. We wrote a simple function computing Fibonacci numbers using an exponential algorithm. Here are the results for computing Fib(N) for value N = 5, 15, 25, 30:


Requests per second: 13789.24 [#/sec] (mean) Fib(5)
Requests per second: 3202.31 [#/sec] (mean)  Fib(15)
Requests per second: 118.94 [#/sec] (mean)   Fib(25)*
Requests per second: 8.40 [#/sec] (mean)     Fib(30)**

*only 1000 requests were performed to save time

**only 100 requests were performed to save time


Requests per second: 8842.70 [#/sec] (mean) Fib(5)
Requests per second: 8892.66 [#/sec] (mean) Fib(15)
Requests per second: 5581.37 [#/sec] (mean) Fib(25)
Requests per second: 737.56 [#/sec] (mean)  Fib(30)

In case where N = 5, the page required almost no computation at all. In this case it was visible just how well optimized FPM really is. It was over 50% faster than HHVM FastCGI server which indicates that there is still a lot of room for improvement in our implementation. However at N = 15 the amount of computation already shifted the balance to HHVM’s advantage. Where for HHVM the bottleneck was still the network, FPM was clearly CPU bound at this point with a result almost 3x worse than HHVM. At N = 30, HHVM just in time compilation really shined, yielding results almost 80x faster than PHP.


Now to the fun part: how to get HHVM FastCGI working on your machine? For popular Debian-based distros we prepared a set of pre-built packages:

Ubuntu 12.04

echo deb precise main | sudo tee /etc/apt/sources.list.d/hhvm.list
sudo apt-get update
sudo apt-get install hhvm

Ubuntu 13.10

echo deb saucy main | sudo tee /etc/apt/sources.list.d/hhvm.list
sudo apt-get update
sudo apt-get install hhvm

Debian 7

echo deb wheezy main | sudo tee /etc/apt/sources.list.d/hhvm.list
sudo apt-get update
sudo apt-get install hhvm


If your distro is not on the list, you can still run HHVM FastCGI, with slightly more work (or you can take the scripts from that package and repackage it for your distro). First, install the latest release of HHVM. To run the server in FastCGI mode, pass additional parameters to HHVM runtime:

cd /path/to/your/www/root
hhvm --mode server -vServer.Type=fastcgi -vServer.Port=9000

The server will now accept connections on localhost:9000 (only TCP sockets are supported for now). To turn the server into a daemon, change the value of mode to:

hhvm --mode daemon -vServer.Type=fastcgi -vServer.Port=9000

All the usual options accepted by the HHVM runtime are also available in the FastCGI mode. Please make sure that HHVM runs from the directory where you wish to serve PHP files.

Once the HHVM FastCGI server is up and running, it’s time to appropriately configure your webserver of choice. As an example, we include instructions for Apache and Nginx.

Making it work with Apache

The recommended way of integrating with Apache is using the mod_proxy_fcgi module. First, you need to enable mod_proxy and mod_proxy_fcgi modules, if you haven’t done so already. To enable the modules make sure you have the following symlinks created:

cd /path/to/your/apache/conf
ln -s ../mods-available/mod_proxy.load mods-enabled/mod_proxy.load
ln -s ../mods-available/mod_proxy.conf mods-enabled/mod_proxy.conf
ln -s ../mods-available/mod_proxy_fcgi.load mods-enabled/mod_proxy_fcgi.load

Next up, you need to insert a directive instructing Apache to send traffic to the FastCGI server. You can do so by inserting the following line in your apache.conf / httpd.conf file.

ProxyPass / fcgi://

Please note that this will route all the traffic to the FastCGI server. If you want to route only certain requests (e.g. only those from a subdirectory or ending *.php, you can use ProxyPassMatch, e.g.

ProxyPassMatch ^/(.*.php(/.*)?)$ fcgi://$1

Consult Apache docs for more details on how to use ProxyPass and ProxyPassMatch.

Making it work with Nginx

The default FastCGI configuration from Nginx should work just fine with HHVM FastCGI. You will need to add the following directives inside one of your location directives:

root /path/to/your/www/root/goes/here;
fastcgi_index  index.php;
fastcgi_param  SCRIPT_FILENAME /path/to/your/www/root/goes/here$fastcgi_script_name;
include        fastcgi_params;

The traffic for the surrounding location directive will then be routed to HHVM.

What’s next?

There are a couple of important features still missing from the initial implementation. The most notable is support for local UNIX sockets. At present, only less performant (however more flexible) TCP sockets are available. The priorities for this release were:

  • Correctness,

  • Getting the architecture of the solution right, so that performance can be improved in the future.

We haven’t really done any profiling on the new server yet. It is therefore quite likely that there is some low hanging fruit waiting to be picked. We are definitely looking forward to improving HHVM FastCGI performance in the future releases.


  • Robert Lidberg: This is so useful! Thanks! Will benchmark for comparison later this week.
  • Joseph Scott: Did the PHP-FPM tests use an opcode cache? Which version of PHP did the PHP-FPM tests use?
  • klausi: "The following php.ini and php-fpm.ini files were used. " ==> where are those files? Did you run the PHP-FPM benchmark without an opcode cache? Then the results are broing, please repeat with APC enabled and clarify that in the post.
  • iwankgb: I would love to know it too. Another interesting comparison could include hhvm+fastcgi+webserver and hhvm on its own.
  • Paul Tarjan: Juliusz is currently back home in Poland and fast asleep. I'll get him to reply as soon as he gets up. If you want to re-create the benchmarks I'll happily link to your post.
  • Sandeep: Thanks for the update. Benchmarks are good and exiting. Could you please provide the php and hhvm configurations you ran the test?? Anyway hhvm is promising.
  • Nick: I notice that in your examples, the HHVM appears to be serving one single site - will fcgi work across multiple virtual hosts, or will it require a single instance per? I know the SCRIPT_FILENAME can be changed in nginx to not use a hardcoded filename
  • Paul Tarjan: The author says yes:
  • Paul Tarjan: It should work exactly the same as PHP FPM, so yes, it can host many sites.
  • HHVM 2.3.0 and Travis CI « HipHop Virtual Machine: […] We released a new version of HHVM today. This one includes all the hard work from our lockdown (detailed post to follow) and the ability to use HHVM with FastCGI. […]
  • Nick: Awesome! I figured it would, but I wanted to make sure!
  • Nick: Awesome! Huge shout out to you guys, this is pretty awesome! I've fiddled with HHVM before, but I'm super excited about this! Thanks!
  • Oskar Hane: This is great, thanks guys! Can't wait to try this.
  • Simon: This looks very promising, looking forward to undertaking some performance benchmarks myself :)
  • Julius Kopczewski: Cool, I would like to link to other benchmarks, so please go ahead.
  • Julius Kopczewski: So, yea, that was the first thing I checked after I run the results the first time. It was enabled in php.ini. After giving it some thought, the only other thing that could possibly influence the results would be the compilation flags. I followed the official building from source instructions, however I could have screwed it up obviously. Please, feel free to roll your own benchmarks and we will link to them from the blog post.
  • Julius Kopczewski: Heh, yea. I wanted to post the files, then it turned out we don't have a good thing for posting the files so I forgot to do that. Let me tell what I did instead. I used the default php.ini file that came along with the PHP version that was released around September. I then made sure that opcode cache is enabled and it was. I remember retrying with it enabled explicitly.
  • Julius Kopczewski: php.ini file was the one that comes bundled with PHP sources. I just made sure that opcode cache is enabled. I did not make any tweaks to the HHVM configuration so I believe it would be equivalent to what comes with the OSS sources.
  • David Carrero: I´ll try in plesk installation, do you test this ?
  • N1: Nice, got my symfony2 app running with hhvm-fastcgi :-) Only missing piece for full support seems to be Intl/ICU.
  • Julius Kopczewski: I ran HHVM as a webserver too. It is quite capable, since it's what runs FB in production. In terms of I/O performance it seemed to do just slightly better than PHP-FPM + nginx. By that I mean that for "hello world" sites it would deliver about 10-15% better throughput.
  • Robin: Will you be able to provide a working vagrant box (or something like that) so the complete config is available as a working set somewhere?) This would more easily allow other projects to have a running start into checking hhvm compat as well as looking at a complete working example of the config+hhvm+project etc! Looking forward to it!
  • Josh Koenig: Getting 20 req/sec from a simple WP install sounds like there was no opcode cache enabled. If so, these benchmarks aren't very meaningful. :
  • Joel Marcey: Hi Josh -- opcode cache was turned on. This should hopefully clear things up a bit:
  • panzi: You could make a github gist and embed it in the article.
  • Julius Kopczewski: I would welcome any independent tests. I will also ask Paul to try to replicate the results independently. If they don't match, I will update the post with the new results. I will also link to any independent benchmarks that you post in the comments.
  • Wolf: I am getting the following error on CentOS. Does anyone know what might be causing it? upstream sent unsupported FastCGI protocol version: 72 while reading response header from upstream I am running hhvm as a daemon on port 9000 and copied the NGinx config here.
  • Miguel Clara: I was tried to test this with nginx, but can't get past "Not found" location ~ .php$ { fastcgi_param SCRIPT_FILENAME /var/www/blog$fastcgi_script_name; fastcgi_pass; fastcgi_index index.php; include /etc/nginx/fastcgi_params; }
  • diego: Hi, on my Ubuntu 12.04 there is only apache2.2 from repos, but for mod_proxy_fcgi I need 2.4. Have you tested this on 12.04? Have you custom build apache2.4?
  • Miguel Clara: *I was trying! Btw "root" is defined previous to the .php location, forgot to mention that!
  • lubosdz: I also doubt about objectiveness of these benchmarks. 20 requests per sec is something wrong with environment setup. Also configuration (socket unix/tcp) may give different results. Even though HHVM is probably nicely performative, yet independent professional benchmarks would be more welcome, sorry :-)
  • Las: Same, how did you resolve it?
  • Julius Kopczewski: Please submit a bug report indicating what happens exactly. This might be an easy fix, provided it's a problem.
  • Paul Tarjan: This is when you forget to start HHVM with the "-vServer.Type=fastcgi" option. Your sever is responding with normal "HTTP 1/.0" header instead of the binary protocol.
  • Miguel Clara: I was using the "hhvm-fastcgi" init script from ubuntu which points to a config file already create. using the shell command *AFTER* cd into the root dir it worked! This makes me wonder however how should I handle multiple sites... like we do with php-fpm pools, but I guess I'll have to read more about that! I wasn't able to run ab tests though.... hhvm process crashes... I see this is the log: perf_event_open failed with: No such file or directory perf_event_open failed with: No such file or directory perf_event_open failed with: No such file or directory receiving index.php
  • Carlos Icaza: I tried to install using repository technique, but the package is missing for i386 architecture... Debian 7.2 - VirtualBox
  • HHVM får FastCGI support - GOTCHA: […] Du kan læse meget mere og se benchmark testene her. […]
  • Paul Tarjan: We don't support i386
  • Andy: Could you post the hhvm-fastcgi init script ?
  • Naveen Valecha: Thanks for the sharing this.Have anyone implemented it on windows server.
  • Paul Tarjan:
  • Sang Le: When will it support multiple instance. Example support for multiple site of apache or nginx. Current it hardcode in the /etc/hhvm/server.hdf, so i should copy the init.d script to another, define another port + document root for other site.
  • Mike: Its the one that comes with the ubuntu package!
  • Paul Tarjan: I just released 2.3.2 which should fix the issue.
  • Zack Gomez: Hi Paul, When will 2.3.2 prebuilt unbuntu packages be pushed?
  • Paul Tarjan: I pushed them yesterday about 12 hours ago.
  • Random Lists » PHP 5.5 vs HHVM vs Node.js: […] the HHVM team used the Fibonacci benchmark ( I tried the same. What I did was vary the number of fibonacci numbers computed and measured the […]
  • Neil Girardi: Hi, On Ubuntu 13.10 after running sudo apt-get install hhvm-fastcgi I get "E: Unable to locate package hhvm-fastcgi"
  • Paul Tarjan: Sorry, I broke it when I shipped 2.3.2. It is fixed now.
  • Sandeep: Thank you. I just want to be sure about opcode cache. Even we got good results on our internal benchmarks.
  • Jim Norton: on apt-get update I get this error: W: GPG error: precise Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY ....
  • Paul Tarjan: Yeah, I just signed the packages. You're going to need to do this: wget -O - | sudo apt-key add -
  • Our Future Technology Partners | […] own Hiphop PHP compiler, which compiles PHP into C++ code to make incredible performance advances compared to the regular PHP interpreter and moderate performance advances over opcode caching. This system is being actively developed and […]
  • Julien: This worked for me, but now it can't find hhvm-fastcgi. It worked last week ! I guess you pushed this version in a hurry :P
  • Paul Tarjan: Which distro?
  • Scott: I'm a bit confused. Your first wordpress test shows 22 requests per second from php fpm, but my own nginx/php-fpm 2GB vps does over 1300 requests per second with apache bench against In the comments, you say php-fpm is ran with opcache, but the over 2 second response time disagree. My site does under 600ms pageloads with wordpress php-fpm. Something is wrong with your test. You either aren't using opcache, or your hardware is really, really bad.
  • Scott: Server Software: nginx Server Hostname: localhost Server Port: 80 Document Path: /?p=1 Document Length: 0 bytes Concurrency Level: 50 Time taken for tests: 15.860 seconds Complete requests: 1000 Failed requests: 0 Non-2xx responses: 1000 Total transferred: 359000 bytes HTML transferred: 0 bytes Requests per second: 63.05 [#/sec] (mean) Time per request: 793.023 [ms] (mean) Time per request: 15.860 [ms] (mean, across all concurrent requests) Transfer rate: 22.10 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 1.5 0 9 Processing: 398 775 268.0 740 2047 Waiting: 398 775 268.0 740 2046 Total: 398 776 269.3 740 2055 Percentage of the requests served within a certain time (ms) 50% 740 66% 796 75% 846 80% 884 90% 972 95% 1280 98% 1871 99% 1958 100% 2055 (longest request) This is php-fpm with opcache with fastCGI cache off. What's odd about it, besides being drastically faster than your results, is if I increase the concurrency to 500 from 50, the requests per second goes up to 434 requests per second
  • Grim: How? I same with u,but is not ok. e.g.symfony/web/app_dev.php/demo/ is 404 not found.
  • Julius Kopczewski: You have only 359 bytes per request and only 22.10 of transfer? Did you install the sample data at all? Note that in my test there seem to be much, much higher transfer, and that's despite fewer requests served. I would expect you are hitting a different page or your page contains different data. Either way, I will ask somebody to re-run the test when they are free.
  • Julius Kopczewski: Perhaps you're getting 302 or something like that? Let me know if I read the stats correctly.
  • Julius Kopczewski: In particular, take note of that "Non-2xx responses: 1000". All results should be 200, and they were in my case.
  • Julius Kopczewski: See my replies below.
  • Ajinkya: What is this hip hop virtual machine, does it do hip hop when you run any program on it?
  • Julius Kopczewski: No, only if you hit it hard.
  • Scott: You make a good point. I actually had a full wordpress sitting there, but apparently when apache bench is run on /p=1, it's actually having 404 errors, despite the fact that going to loads a real page. Testing with works fine, fails. I also realized I had fastCGI cache set to 1s (which sits on tmpfs), which made a crazy performance difference. Server Software: nginx Server Hostname: Server Port: 80 Document Path: / Document Length: 126772 bytes Concurrency Level: 100 Time taken for tests: 7.630 seconds Complete requests: 1000 Failed requests: 0 Total transferred: 127048000 bytes HTML transferred: 126772000 bytes Requests per second: 131.05 [#/sec] (mean) Time per request: 763.048 [ms] (mean) Time per request: 7.630 [ms] (mean, across all concurrent requests) Transfer rate: 16259.83 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.4 0 2 Processing: 31 726 149.8 757 936 Waiting: 18 700 147.4 735 885 Total: 33 726 149.4 757 936 Percentage of the requests served within a certain time (ms) 50% 757 66% 776 75% 794 80% 805 90% 839 95% 866 98% 892 99% 907 100% 936 (longest request) This is ab -c 100 -n 1000
  • Scott: I have a question. If you use nginx with fastCGI support, with hhvm, can you use nginx fastCGI caching? It should work, logically, but I'm just checking.
  • Julius Kopczewski: So curious, are the updated results with or without the caching?
  • Julius Kopczewski: Not sure how it works. I would have to understand what does the caching do on the protocol level. FastCGI is a stateful protocol, however the entire state is contained within a transaction. If therefore cache is used to skip an entire transaction I don't see any issues. Otherwise I would have to understand the internals to know what is needed to support it.
  • Kasper Isager: I'm happy to announce that Vagrant LNPP now includes optional support for HHVM FastCGI: Thanks heaps for this article, it was a great help in getting things set up!
  • mig5: Doesn't seem to play nicely with Percona Server (drop-in replacement for MySQL) ? # /etc/init.d/hhvm-fastcgi start /usr/bin/hhvm: /usr/lib/ no version information available (required by /usr/bin/hhvm)
  • slurm: test using wordpress: ab -c 100 -n 1000 http://localhost/wordpress/ Without hhvm: (apache 2.4.6 + modphp 5.5.3) Requests per second: 108.79 [#/sec] (mean) with apache 2.4.6 + hhvm 2.3.1: Requests per second: 324.37 [#/sec] (mean) cpu: i5 760. ------------------------------------------------------ Server Software: Apache/2.4.6 Server Hostname: localhost Server Port: 80 Document Path: /wordpress/ Document Length: 7673 bytes Concurrency Level: 100 Time taken for tests: 3.083 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 7914000 bytes HTML transferred: 7673000 bytes Requests per second: 324.37 [#/sec] (mean) Time per request: 308.293 [ms] (mean) Time per request: 3.083 [ms] (mean, across all concurrent requests) Transfer rate: 2506.87 [Kbytes/sec] received
  • Paul Tarjan: Awesome, thank you. Let us know if there are any issues.
  • Paulo Figueiredo: I'v set up nginx with hhvm but, any file .php returns me "Not found" except index.php that returns me "Running on HHVM version 2.3.2." Some of my configurations /etc/nginx/sites-enable/default location ~ .php$ { root /usr/share/nginx/www; fastcgi_pass; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /usr/share/nginx/www$fastcgi_script_name; include fastcgi_params; } /etc/hhvm/server.hdf Server { Port = 80 SourceRoot = /usr/share/nginx/www/ DefaultDocument = index.php }
  • Paul Tarjan: That looks right. All your other files are in "/usr/share/nginx/www/" and the www-data user has access to read them?
  • Paulo Figueiredo: Setup a test environment for HipHop VM. The final VM will contain HHVM, Nginx, PHP, MySQL, ab.
  • Paulo Figueiredo: Yes! I guess! :) -rwxrwxrwx 1 www-data www-data 383 Jul 7 2006 50x.html -rwxrwxrwx 1 www-data www-data 2759 Jan 5 14:17 default.txt -rwxrwxrwx 1 www-data www-data 51599 Set 27 11:47 image.php -rwxrwxrwx 1 www-data www-data 157 Jan 5 14:27 index.html -rwxrwxrwx 1 www-data www-data 22 Jan 5 14:48 index.php -rw-r--r-- 1 www-data www-data 5 Jan 5 16:01 root@rack:/usr/share/nginx/www# pwd /usr/share/nginx/www
  • Paulo Figueiredo: Yes! I guess! :) -rwxrwxrwx 1 www-data www-data 383 Jul 7 2006 50x.html -rwxrwxrwx 1 www-data www-data 2759 Jan 5 14:17 default.txt -rwxrwxrwx 1 www-data www-data 51599 Set 27 11:47 image.php -rwxrwxrwx 1 www-data www-data 157 Jan 5 14:27 index.html -rwxrwxrwx 1 www-data www-data 22 Jan 5 14:48 index.php -rw-r–r– 1 www-data www-data 5 Jan 5 16:01 root@rack:/usr/share/nginx/www# pwd /usr/share/nginx/www
  • Jim Walker: I'm guessing this is not something that could ever be installed on a cPanel server?
  • Scott: Thank you for your response. I don't have the information to give you on that as I'm not a developer, just a guy who likes webservers.
  • Scott: Without caching. The setup is: Wordpress 3.8.1 Arch Linux (current, rolling distro) nginx-custom-dev from aur 2GB of ram (32GB ram box, rented from raid 10 hard drives of some variety (unknown) No fastCGI cache
  • Scott: I should mention, 8 virtual cores on a xeon e3 1270v3 (quadcore with hyperthreading)
  • Scott: Not for a long, long time, Jim.
  • Scott: How did I miss the most important parts... php 5.5 with opcache (the built in variation)
  • Julius Kopczewski: I see, I will ask someone to rerun the test. I can't do it right now myself because I'm terribly busy at least until 15th. Thank you very much for doing the tests!
  • alexodus: +1
  • Drupal Tuning | Annotary: […] […]
  • diego: Has anyone had luck with Ubuntu 12.04 and Apache2.2 now? Or is there a possibility to install Apache2.4 with mod_proxy_fcgi on Ubuntu 12.04? 14.04 LTS is not that far away, but I don't want to wait 3 month :)
  • mods missing in apache2 : a web developer's ...blah blah blah... blog :): […] guys over at Facebook. To say that it is impressive, is an understatement – take a look this post. They got a WordPress installation running at 23 concurrent requests per second, all the way up to […]
  • PHP HHVM with specific virtual hosts in apache : a web developer's ...blah blah blah... blog :): […] article follows on from a previous post which is here, which in turned followed on from this post here. I decided to write this post as I have a number of sites inside my development box and I wanted to […]
  • Migrate Wordpress to Amazon EC2 | | Open Source Writeups: […] Checkout the primer here:  HHVM […]
  • Bob: Hi all, For some unknown reason HHVM-fastcgi won't fire the mysqli() function. I've found that HHVM is not supporting mysqli but I thought hhvm-fastcgi was... Can somebody help? More info:
  • HHVM revisited - SitePoint: […] on December 17th, 2013 the HHVM team announced FastCGI support. FastCGI is a protocol for a server's communication with the application […]
  • Thomas Decaux: Tried to run my framework eBuildy on it, everything is working fine, except its very slow (10x more than with PHP5.5+OpCache). I ran a ab test, I saw my CPU grows to 100% ;( Is there setting to tune this? Thanks,
  • Paul Tarjan: Run it a few times. We take a while to warm up. Also, if you are running the command line, you will want `-vEval.Jit=true` to turn on the JIT.
  • Nginx + HHVM FastCGI 配置指南 | Qing's Blog: […] FasterCGI with HHVM 由于 网站被Qiang,可以通过hhvm.cn的镜像查看。 […]
  • HHVM, Nginx and Laravel | victor - note: […] Information on installing HHVM on other server distributions (including newer Ubuntu’s) can be found here. […]
  • A Look at Hack, the PHP Replacement in HHVM - SitePoint: […] few things that are worth mentioning are the recent support for FastCGI and the integrated […]
  • cabana: HI I have a qustion. Would someone tell me why I can't upload file over ftp funcion in PHP when I'm using HHVM? Maybe Someone had a similar problem and would tell me how to fix it ;)
  • Nick: I think maybe it should be mentioned that you'll need to add 'IP =' to server.hdf. Otherwise (and this is my experience on Debian using the repos you have above) hhvm will bind to and not localhost.
  • Franky: Have you ever run performance tests how good it performs when the cached WordPress Template comes out of a Ramdisk?
  • Robert: I'm using Ubuntu 13.10 with Apache2: I installed HHVM and it is running on port 9000... I cannot find these config files: mod_proxy.load mod_proxy.conf mod_proxy_fcgi.load Where can I download them from???
  • PHP + FastCGI + HHVM | REMO Ideas: […] La página de como instalar hhvm oficial es esta […]
  • Ruben de Vries: fast-cgi can spawn a big pile of workers, hhvm is just one process how does this compare? is this configurable somehow?
  • Hack Isn’t PHP | Roger Stringer: […] and they stand to gain a lot if they can make it faster, so they wrote their own runtime that’s much faster than the official one. This is exactly what the PHP world needed: making its already-fast […]
  • Geo: Trying to send SMTP mail i get error: Undefined function: stream_socket_enable_crypto
  • necenzurat: same error here, but i manage to install wordpress, on it so no probem except the notice
  • My Journey with HHVM-Pt.1 - Tech Samurais: […] need to run the same tests as the ones on the HHVM blog and compare the results. These test will be run against our project. Let’s see what we get! […]
  • Crazyzurfer: Doesn't work for ubuntu 14.04 :(
  • Mark Jaquith: Yep, it's working just fine for me. Nginx doesn't really care if it's PHP-FPM or HHVM it's sending the requests to. Its caching is unaffected.
  • Install HHVM | Janik von Rotz: […] Prebuilt Packages on Ubuntu 12.04 FasterCgi with hhvm FastCGI configuration on the HHVM GitHub […]
  • Dave Harris: A PHP-FPM worker process runs under the group & user IDs of the owner of the site being served, set by the ownership of the document root for that site. As I run a server supporting multiple clients, this is invaluable. Can HHVM do this without me having to set up one VM per site? Also: I manage the sites using ISPConfig. As the latter supports configuring sites to use FastCGI, I presume that if HHVM is the "other side" of FastCGI, it should work... but if not, it shouldn't be too hard to make it work :) Any opinions?
  • Paul Tarjan: HHVM uses threads to serve each request, where PHP5 uses processes. Sadly with threads we can't change UserID for each request.
  • Setup HHVM on Ubuntu 13.10: […] can follow most of the directions here at the HHVM blog however there are a few other things to […]
  • YUE: I run the SPECWeb2009 benchmark on the SUT. And at the SUT, I use the Nginx + HHVM3.2.0 as server. However, the requests per second is not good, and the hhvm process always crashes.looking forward to your reply!
  • HHVM at it’s glance – speed comparision – Fohlen's Blog: […] a interesting article I found comparing HHVM with […]
  • ck: Despite the age, you guys should go back and correct this page/benchmark for the obvious error with wordpress. "Requests per second: 949.21" "Time per request: 1.054 [ms]" This never happened in reality. Something clearly went wrong and those are empty replies with error messages if you examine the html of results. Multiple independent benchmarks confirm this, even after "JIT warmup" HHVM is perhaps four times faster than php 5.5, certain never "40x" faster for wordpress.
  • Why Facebook is making a PHP renaissance | KidsIL: […] performance of HHVM has been reviewed in a few articles, and it seems to have pushed the core developers of PHP, as the last versions […]
  • Vozidea: I tried to install it on Ubuntu 14.04 and followed instructions as i describe in but i´m having the 404 problem. Perhaps someone can help, because i can't find the solution.
  • laurens: There is also a possiblity for one process per client. I guess. So there is room for changes. One per thread is the better way of doing things in my opinion.
  • xeridea: "Only 23 requests per second seem to indicate that WordPress is computationally very expensive to run in an interpreter." This is more a sign that WordPress is horribly inefficient beyond reason or repair. Anyone even remotely concerned about performance should not use it. Years and years of horrible hacks on top of a bad framework to begin with, the devs refusing to fix it. Fibonacci? What kind of a test is this? I am sure everyone has highly specific loops like this on their website. Perhaps some better tests? The legitimate tests performed by others that don't result in a thousand error pages (from you know, crashes, and incomplete features), show more reasonable performance boost (like 2-4x, but HHVM performance is extremely variable). I am looking forward to PHPNG, which has comparable performance, with potentially more, doesn't crash, passes all the unit tests, is compatible with all extensions, is easy to install, has ALL the features, you don't wait years for features, and the best support.
  • DRJ: Any updates on this test? Please let's know how far HHVM has gone and how the results stack. Thanks.
  • Fred Emmott: I'll hopefully have a larger update to share soon, though you can see how we're trying to investigate performance here:
  • HHVM with Nginx fastcgi not working properly | Zesati Answers: […] I've followed a stairs mentioned here: […]
  • GT: I doubt php-fpm installation had accelerator module. At the post date maybe the built-in opcache module wasn't available, but for fair comparison an apc could be essential. I don't know anyone who using php-fpm without one of these kind of modules (opcache/apc/zendaccelerator/etc.)
  • HHVM e Hack Language: Compartilhando experiencias | Grupo de Desenvolvedores de PHP de São Paulo: […] O mesmo vale para o HHVM, que oferece pacotes de instalação para as principais Distros Linux e suporte para FastCGI, podendo ser executado nos principais servidores […]
  • HHVM bekommt FastCGI-Support und wird kompatibel mit Apache, Nginx, Lighttpd, ... - […] der Beschreibung der FastCGI-Implementierung wird deutlich, dass Facebook stark auf CPU- und RAM-Optimierung hingearbeitet hat und die Erfahrung […]
  • How to Setup HHVM on Ubuntu 14.04 Server with Apache 2.4 – Part 1 | Runtime Reflection: […] […]
  • Faxicon Dev: I'm still fail to build this one on plesk 12 with centos 7 , return to normal php
  • Homsa Lomsa: I'm benchmarking a PHP with one database insertion per request, but it seems like nginx/php-fpm is a bit faster than nginx/hhvm ~700 requests / sec for nginx/php-fpm against ~500 requests / sec for nginx/hhvm. Any idea?
  • Fred Emmott: There is not enough information here to really give an informed response - that said, we are often slower at small benchmarks, and we do not consider this a problem as long as it is not true for real world applications; in our experience, benchmark performance and real world performance are rarely related.