HipHop For PHP: Who Benefits, Who Doesn’t

There’s been lots and lots of discussion regarding the Facebook “Hyper PHP” release of HipHop for PHP. This new technology is an in-production converter for PHP that takes PHP code, converts it into C++ code, and creates a complete binary that can be run on a server natively. Facebook claims improvements of up to 50%, and their model represents a shift in thinking about scripting languages like PHP.

Ostensibly, lots of people are going to be thinking about how this will benefit them and their organizations. Here are some thoughts on who will benefit and who will not benefit.

Who benefits
There are lots of benefits for producers of large-scale web applications written in PHP. The ability to convert PHP code into something else that is more efficient without having to retrain their developers will ultimately reduce server load and deployment costs.

In particular, anyone running a web application with more than two servers will certainly benefit, as there is likely the traffic necessary for such a large web application. With a 50% improvement, one could conceivably use only one server; however, for redundancy reasons, it’s likely a good idea to maintain at least two web servers.

Others who benefit include those who distribute PHP code to clients directly. The ability to deploy an application on a web server in a compiled format ensures that reverse engineering is more difficult and protects intellectual property. There is considerable debate as to whether or not compiled or obfuscated code is worthwhile; given that the product designed by Facebook must be efficient, the idea of distributing a PHP-based binary makes a lot more sense.

Who doesn’t benefit
For all the benefits, there is a large group of PHP developers that won’t benefit: the average, every day developer. There are a vast number of websites that have a single server and not very much traffic; there are also lots of sites that run on shared hosts, or sites that have multiple sites on the same server. Since HipHop runs one web application at a time (with a built-in webserver), it’s impossible at the moment to run more than one website on a box. This is obviously less than optimal for most folks, and will limit adoption.

Also, early adopters of PHP 5.3 won’t be able to use HipHop straight away. Currently, it supports PHP 5.2 (as most of Facebook is written in PHP 5.2), though there are plans to modify HipHop to support PHP 5.3.

Bottom Line
HipHop is still pretty awesome, and will certainly change the way PHP applications are developed. There are great opportunities here, and Facebook has certainly developed a revolutionary system. What will ultimately happen remains to be seen; regardless, it should be an exciting year for PHP development overall.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

Sjan Evardsson (@evardsson) wrote at 2/2/2010 9:08 pm:

I was disappointed by the “one application at a time” piece of this. I was hoping for something a little more modular and capable of being used across multiple applications on one server.

That being said, if I could move all my legacy apps to their own VM and set up a new VM for each new app we build … (gears turning here.)

While I am an early adopter in many ways, this is one that I will have to see play out a bit first. I will likely set up some test apps in VMs and see what kind of gains I can manage, and see how it affects the build -> test -> deploy -> update -> test -> deploy (ad infinitum) cycle.

Joel Clermont (@jclermont) wrote at 2/2/2010 9:32 pm:

What would prevent someone from running multiple apps on a box on different ports than using Squid in reverse proxy mode to direct internally to the right port? Definitely not going to work in shared hosting, but for those of us running our own servers with a couple dozen “medium”-sized sites, this isn’t a deal breaker. Thoughts?

php/ajax wrote at 2/2/2010 9:33 pm:

I was just thinking that it would be great if it was possible to load HipHop’s c++ binaries in the same way we can include .phar and .php files

The one thing is that we they will have to security checks to make sure that the c++ extensions executed inside a sandbox.

Brandon Savage (@brandonsavage) wrote at 2/2/2010 9:37 pm:

@Joel, I think that’s certainly an option. I didn’t mention it outright, mostly due to the fact that the released version isn’t explicitly designed to do that. Bear in mind that Facebook’s use case was high-traffic web servers that serve unique content on each page view, and for high-traffic sites I think this is a fantastic use case.

Your better bet might be what was suggested above, creating a VM for each app and running it that way.

Digitivity @ The Digital Life & Tools Blog (@digitivityorg) wrote at 2/3/2010 3:48 am:

Is it clear at this time if HipHop integrates seamlessly with an existing PHP installation + web application?

I.e., you could have most of your application compiled, and then if you want to add a page (or class) or two, you could just add it in a .php file until you can get around to re-compiling and replacing the whole app.

robo47 (@robo47) wrote at 2/3/2010 4:50 am:

@brandonsavage
I don’t thinkcreating a VM for each app will really “help” here. It produces much more overhead, all standard-services + programs of the used server-os run X times (webserver, database-server, cron) instead of one, resulting in more cpu-usage and more memory-usage, the two things hiphop should lower. I don’t think it makes any sense to create VM’s just to run hiphop because you will propably lose a lot or all of the performance-gain. And for running a webserver in each VM you will too need at least one IP for each VM to have it’s own Port 80 for the webserver.

A simple reverse-proxy setup (lighttpd, nginx, apache, … )? saves resources and since in my opinion a webserver doesn’t have to be “reverse-proxy-usable” there isn’t any explicit design-thing for hiphop to be able to be used behind a reverse-proxy.

Markus Wollny (@mwollny) wrote at 2/3/2010 8:15 am:

I have to agree with @robo47. There shouldn’t be much of a problem using nginx’s reverse proxy feature or Apache’s mod_proxy to allow for per-host deployments, if necessary even on a per-directory basis. There will of course be a certain administration overhead and the performance gain when compared to a more conventional deployment that’s using an opcode-cache like eAccelerator or XCache may not be worth the hassle. So I think I’ll disagree on the assumption that anyone using a loadbalanced 1+x webserver setup will be well advised to jump on that train. This is a very special beast and it’s very likely that even if you’ve got a somewhat larger PHP deployment it is not for you.

Jordan Walker (@jorwalk) wrote at 2/3/2010 9:05 am:

I am interested to hear what Rasmus has to say.

Brandon Savage (@brandonsavage) wrote at 2/3/2010 11:46 am:

Rasums actually tweeted about it. He mentioned that most people will run into typical bottlenecks like database or file system, and that HipHop probably wouldn’t help in that case.

moronkreacionz (@moronkreacionz) wrote at 2/4/2010 8:06 am:

Well, its exciting to see the efforts of such wonderful people.

@Brandon: I have a different query here:
How about just transforming userdefined-function-libraries/blocks of PHP code as extensions using Hiphop ?

Since most of the large traffic sites working with PHP would have diversified usage of libraries/database/memcached/file handling/caching mechanisms in place..

Would that be certainly handled in similar efficient way?

-Vj

moronkreacionz (@moronkreacionz) wrote at 2/4/2010 8:08 am:

I think @digitivityorg meant the same thing ?

terry chay (@tychay) wrote at 2/5/2010 8:38 pm:

Actually, Facebook is technically running more than one PHP application at the same time—when they release an update. What goes on is two HipHop servers are started and they are switched over at runtime using port takeover.

The basic issue is for HipHop to work, it has to survey the code of your entire application. If you have multiple applications you have to either build multiple binary projects (and multiple servers), or build it as a large single project. This means Digestivity’s use case is an explicity no-no in HipHop.

Similarly moronkreacionz is out since the whole thing is built “as a piece” and not as a library. The exception is if you’ve already isolated that part into a highly-cohesive unit that is loosely coupled via web API. In that case, you can just launch it “as-is” if it compiles at all.

Copyright © 2023 by Brandon Savage. All rights reserved.