FasterCGI with HHVM

http://www.hhvm.com/blog/1817/fastercgi-with-hhvm

by seaghost • 13 years ago

110 31 13 years ago

nikic• 13 years ago

Please, if you do performance benchmarks, always run them with an opcode cache (PHP 5.5 + opcache would be the obvious choice). Without it your benchmark becomes completely meaningless. I also feel like HHVM devs should be aware of this, so likely the numbers are deliberately misleading.

Apart from that, having FastCGI support is of course nice.

thezilch• 13 years ago

And using something like `wrk` and not `ab`...

stormbrew• 13 years ago

Or at least say upfront if you are or not. I think it's not exactly unreasonable to compare "out of the box" to "out of the box", but it should be clear that's what you're doing.

Really I think this sort of thing should be encouragement to make the opcode cache no longer a default-off additional thing. There's no good reason to have a php deployment -- even one that's just for dev purposes -- that doesn't use an opcode cache.

allanmacgregor2• 13 years ago

Not necessarily there applications like Magento that still only run on PHP5.3 so this numbers are actually relevant.

And we can agree FastCGI support is nice indeed.

randartie• 13 years ago

This post claims that it did: https://news.ycombinator.com/item?id=6925278

jayzalowitz• 13 years ago

Once again, I request that HHVM adopt a hippopotamus as the mascot.. #TeamHipHopPopotamus

girvo2• 13 years ago

My rhymes are bottomless...

MAGZine• 13 years ago

Has something changed? The last time I went to use hiphopvm it didn't even have proper support for php 5.4 (broken namespacing and traits, too I believe). That said, it was basically unusable.

jtreminio• 13 years ago

Do you mean Hip Hop PHP, not VM?

coldtea• 13 years ago

Why should it have "proper support for php 5.4"? It's a quite recent version, and it's not really needed anyway at this moment.

99% of projects out there, from Symphony to Wordpress, are still PHP 5.3 compatible. I don't know any major project requiring traits for example.

kmavm• 13 years ago

(HHVM alum here). Sorry you had a tough time. What's changed is that time has passed, and the HHVM team has put a lot of effort into closing the compatibility gap. If you are aware of a bug with namespaces or traits, let us know at https://github.com/facebook/hhvm/issues

http://www.hhvm.com/blog/875/wow-hhvm-is-fast-too-bad-it-doe...

ptarjan4• 13 years ago

When did you try it last? We spun up a whole team (which I'm on) who's entire goal is to make all of the world's PHP code runable on HHVM. All of the top 20 PHP frameworks work on HHVM now.

http://www.hhvm.com/blog/1499/locking-down-for-performance-a...

jmgtan• 13 years ago

Nice! Looking forward to full support for Symfony2!

girvo2• 13 years ago

I use HHVM in prod. I love it, well done :) I'm actually putting together an app dev "template" for composer to be used with HHVM, and a few compo sable libraries. Not a framework, but good libs and best practices.

kodablah2• 13 years ago

I wish they would be implementing more of the runtime support in PHP itself. Why not make the FastCGI[1] code in pure PHP (like others have[2])? I understand if they don't feel PHP is the best language for daemons, but it would allow so many other developers to use, modify, and comprehend the implementation. I think HHVM suffers from a serious lack of dogfooding.

1 - https://github.com/facebook/hhvm/tree/master/hphp/runtime/se... 2 - https://github.com/kakserpom/phpdaemon/tree/master/PHPDaemon...

Scaevolus• 13 years ago

Miniscule improvements are worth large amounts of money at Facebook's scale. They have an excellent team of C++ and compiler developers working on HHVM, and they see no reason to waste time attempting something in PHP when they could make it run faster in native code without much more initial effort (and probably less effort over time).

kodablah2• 13 years ago

I would hope that their JIT'ing VM could come close to native performance (and rarely faster as tracing JITs can occasionally be). It's about drawing the line somewhere. It's like choosing between Phalcon and Symfony. I understand their internal needs at Facebook, but considering the effort they are putting in to make non-Facebook codebases work I don't think it's too much of a stretch to implement some of the runtime in PHP.

sandfox• 13 years ago

because PHP is "slow" and c is "fast", just about anything thats written in PHP such as FastCGI parser would be daftly slow compared to a counterpart written in c or c++. Most people will not be prepared to sacrifice perfomance just for the sake having everything in PHP

jkopczewski4• 13 years ago

Hi, my name is Julius and I performed the said benchmark while being an intern at FB.

Yes, we used opcode cache in PHP. I definitely don't consider myself to be an expert on PHP configuration. I used the default settings. I was obviously also very suspicious of the results that we got. To the extent, that I consulted a few people about what could be improved about the PHP setup. I remember opcode cache was the first thing I checked, since it's something everyone knows and talks about. It was turned on.

I will update the blog post first thing tomorrow (sorry guys, it's the middle of a night here in Poland, so don't feel like doing it right now).

Cheers.

jkopczewski4• 13 years ago

The only other place where I could have possibly screwed up the results is compilation. I had to build PHP from source, since I wanted to have the "latest greatest" and CentOS has dated packages at times. Though again, I remember just following the official instructions.

If you would like to have the test re-run, you'll have to harass some real FB engineers, since the test was performed on a devbox that I don't have access too anymore. You're also more then welcome to try it yourself and post some alternate benchmarks.

I think I can promise to link to your results from the blog post.

ptarjan4• 13 years ago

You can promise that :)

I'll re-run anything that you need to re-run if you tell me what to do.

allanmacgregor2• 13 years ago

Would it be possible to get the actual test files? I would love to do my own benchmarks against my current stack

jkopczewski4• 13 years ago

I used the php.ini file that comes bundled with the sources. I just think after I ran the benchmark the first time, I enabled opcode cache explicitly just to be sure. I used the Wordpress setup that comes in the sources. Followed the on-screen instructions. That's it.

I tried tweaking the nginx setup, especially the tcp_nodelay & keepalive_timeout settings. It provided maybe 15% speed up, nothing dramatic. I probably didn't collect enough datapoints to be able to reliably tell. In the end, I sticked to the nginx defaults.

sigil• 13 years ago

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.

This note hints at a missed opportunity to employ what some like to call "unix factoring": the listen(2) call can occur outside of your FastCGI worker program, which then only has to call accept(2) on the inherited descriptor, and implement the FastCGI protocol.

Why do it this way?

1. Beyond the accept(2) call, your worker program is now network agnostic.

2. Guess what, you can now test your worker program by feeding it FastCGI protocol data directly on stdin. Just add a mode that uses stdin instead of the fd returned by accept(2).

3. For easy TCP socket support, run your worker under something like this tiny program [1]. For easy Unix Domain socket support, run your worker under something like this tiny program [2]. Your worker program doesn't change because the networking concern has been separated out.

4. If you want, you can put a program which keeps a preforked worker pool between the the listener program and the worker program. This separates out the concurrency concern.

5. No real performance downside; listen(2) is called once for a long-running server process.

[1] tcplisten : https://gist.github.com/acg/4211098

[2] unixlisten : https://gist.github.com/acg/8016689

ptarjan4• 13 years ago

I'd happily take a pull request if you want to get it working.

spencerhakim• 13 years ago

Really want to try this, but no public key provided to verify the packages?

thomaslutz• 13 years ago

Yeah, this is a bit disappointing.

kayoone• 13 years ago

hm cant seem to get it to work with Nginx under Ubuntu 12.04 I followed the instructions and the hhvm seems to be running fine but i get a NOT FOUND from nginx. I basically just changed fastcgi_pass 127.0.0.1:9000; (was php5-fpm) before but the hhvm logfiles are still empty. Any heads up ? Trying this on a Symfony 2.4 project.

FasterCGI with HHVM

Related Stories