

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

======
sigil
_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](https://gist.github.com/acg/4211098)

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

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

------
jkopczewski
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.

~~~
jkopczewski
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.

~~~
ptarjan
You can promise that :)

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

~~~
e-tron
[http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...](http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=all&data=u32)

------
nikic
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.

~~~
stormbrew
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.

------
kodablah
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...](https://github.com/facebook/hhvm/tree/master/hphp/runtime/server/fastcgi)
2 -
[https://github.com/kakserpom/phpdaemon/tree/master/PHPDaemon...](https://github.com/kakserpom/phpdaemon/tree/master/PHPDaemon/Servers/FastCGI)

~~~
Scaevolus
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).

~~~
kodablah
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.

~~~
ptarjan
Whenever we can, we build extensions in PHP
[https://github.com/facebook/hhvm/tree/master/hphp/system/php](https://github.com/facebook/hhvm/tree/master/hphp/system/php)

Many of the older extensions that were imported back in the HPHPc days are in
C since they were much easier to port from php-src if we didn't have to
translate the language.

As for why this was't in PHP, two reasons. It was easier to stay in the
language since our event loop code was already in C++, and most of the gains
we get from writing library code in PHP comes from not having to cross a
language barrier from userland code. The event loop is not the best place for
that.

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

~~~
girvo
My rhymes are bottomless...

------
MAGZine
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.

~~~
ptarjan
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...](http://www.hhvm.com/blog/1499/locking-down-for-performance-
and-parity)

~~~
girvo
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.

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

~~~
thomaslutz
Yeah, this is a bit disappointing.

------
kayoone
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.

