Some recent attention in the PHP framework community has been focused on the recent publication of Symfony 2 Preview benchmarks showing that Symfony 2 outperforms Zend Framework by a factor of 3.5. It also outperforms every other benchmarked framework. This reminded me of the earlier Yii Framework benchmarks which allegedly proved that Yii outperforms Zend Framework by a factor of 7. At this point, the spirit of Glenn Beck would have me demonstrate that 3.5 multiplied by 2 (the number of eyes in Barrack Obama's skull) equals 7, thus proving the existence of a Liberal conspiracy led by a closet Muslim. That's probably bullshit though.

My fellow Zend Frameworkers, we cannot allow this to stand. We must put paid to these wild claims and prove, once and for all, that Zend Framework is the fastest. To present this undeniable truth rooted in solid statistics and Paul M. Jones (aka Benchmark God) inspired techniques, I have created the benchmark of benchmarks. Well, to be honest, I only really edited another benchmark. But still, it will prove Zend Framework is faster than everything else out there.

Before everyone gets too excited, the Symfony 2 Preview performance is quite impressive and it's consistent in my own rerun of the original benchmark. A lot of effort has obviously gone into speeding things up and it shows. My benchmark is not about busting some untruth, but about demonstrating how it is possible to outrace Symfony 2 and Yii with the Zend Framework. I'll dissect the methods after the results are reported .

To ensure the unchallenged fairness of my benchmark, I will publish its entire source code to Github. Unless there are any more sarcastic Irishmen out there, that should be relatively safe. I will also follow in the path of the Almighty Paul M. Jones, in whose shadow all PHP framework benchmarkers will find peace, flowing waters, milk and honey and, if not too much trouble, the extermination of all console noobs who insist that PC gaming is dying. Is that too much to ask, Paul? A little biblical gnashing of teeth would do them good. Paul (may he live forever) promotes using a standardised benchmarking platform, so I will be using an AWS instance reflecting Fabien Potencier's except it will be an m1.large instance instead (the other seeing a few issues in testing) and include some baseline HTML to make sure siege or ab are not misbehaving.

With all these preparations, the stage is set to demolish Symfony 2 and Yii and run them into the ground. Prior to running the benchmark, it's suggested to play the Battlestar Galactica theme tune in the background to set the right mood. Just think of Fabien Potencier dressed up as a Cylon (if only my Photoshop skills were better...sigh). It fits in well with the siege feedback. You can try some HipHop, but those Facebook guys must have been smoking something illegal because it had no impact during the Zend Framework runs. I also experimented with Metallica (surely that would work!) but no...nothing. Quite disappointing.

For those with attention deficit disorder, here are the results:

framework                |      rel |      avg |        1 |        2 |        3 |        4 |        5
------------------------ | -------- | -------- | -------- | -------- | -------- | -------- | --------
baseline-html            |   1.1972 |  5702.79 |  5527.29 |  5775.74 |  5779.59 |  5671.24 |  5760.10
baseline-php             |   1.0000 |  4763.50 |  4718.24 |  4751.51 |  4760.75 |  4763.68 |  4823.32
zend-1.10                |   0.1596 |   760.45 |   766.90 |   764.70 |   758.62 |   752.04 |   759.98
symfony-2.0.0alpha1      |   0.1366 |   650.61 |   641.98 |   655.41 |   653.86 |   656.68 |   645.12
solar-1.0.0beta3         |   0.1131 |   538.86 |   539.76 |   536.95 |   540.63 |   540.10 |   536.87
yii-1.1.1                |   0.0821 |   390.87 |   401.90 |   392.59 |   386.18 |   395.98 |   377.72
symfony-1.4.2            |   0.0441 |   210.22 |   211.20 |   209.78 |   210.72 |   210.49 |   208.92
cakephp-1.2.6            |   0.0406 |   193.56 |   193.84 |   193.35 |   193.27 |   192.57 |   194.75

As you can clearly see, Zend Framework is faster than all other frameworks. More enlightening, we beat both Symfony 2 and Yii. Lithium and Flow were omitted from the original benchmark because besides them being non-functional when forked from Fabien's benchmark (fo

Truncated by Planet PHP, read more at the original (another 6736 bytes)

Truncated by Planet PHP, read more at the original (another 6981 bytes)

No, I’m not talking about a break-dance move that will magically give you extra PHP performance. I’m referring, rather, to a new open source project announced by Facebook. HipHop is a “source code transformer” designed to reduce CPU and memory usage by transforming your PHP code into C++ code.

To understand why this helps, you need to know a little bit about how PHP works. PHP is a scripting language, like Ruby, Python, and Perl. This is great for developer productivity, as there’s no need for the  code to be compiled. The trade-off for this flexibility is in performance, with a scripting language requiring more CPU power and memory than a compiled language such as C++. What HipHop does is transform your PHP code into true C++ code, which can then be compiled into machine code. This is not the sort of thing you would do while developing, but when you are deploying your work you can compile it into the superior C++ code.

HipHop Performance Boosts:

• Web — 50% less CPU usage with the same traffic
• API — 30% less CPU usage with double the traffic

The performance boosts that Facebook has seen is based on its own real-world experience, with over 90% of Facebook servers being converted to HipHop code in the last six months. The benefits released were split into two categories, the Web tier and API tier, and the benefits witnessed for each. The web tier reduced 50% of server load with the same amount of connections, and the API tier saw a 30% decrease, even with a twofold increase in traffic. The difference is explained by the web layer requiring more presentation logic and more abstract information (related information) than the API tier.

What’s the catch?
You’ll have to avoid a few PHP functions, such as eval() and create_function(). Because of the dynamic nature of these functions, the HipHop team was unable to transform them into C++ code; however, these functions are rarely used in most PHP applications in general.

Currently your HipHop code has to run through a custom-written HTTP server bundled with HipHop; however, using HipHop code with Apache is high on the development road map.

While HipHop will increase the performance of your PHP code, it’s not necessarily going to be the silver bullet for your performance woes; for example, if your bottleneck is in your database performance, HipHop will be unable to help you. There’s no need to worry about it making your code slower though, as the entire PHP runtime has been emulated in a way that even the most complicated code will run at the same speed as pure PHP code.

Where can I find it?
HipHop will be released very soon to the open source community, but in the meantime you can read the full write-up on the Facebook blog, or view the Facebook presentation.

What do you think?
I’m interested in doing some benchmarks and seeing how HipHop performs with the SitePoint codebase. Do you think you’ll be checking it out when it’s released?

<script src="http://adscluster.aws.sitepoint.com/openx/adjs.sp.php?region=14&did=adz&adtype=vertical" type="text/javascript">

Related posts:

1. Free PHP Webinar: How to Increase Performance with Caching Zend are running a free webinar today, with a live...
2. Free Performance with MySQL Table Types Last week, SitePoint launched its second Twitaway, giving away a...
3. What’s New in Opera 10 (Part 2: Performance) In the second part of Craig's Opera 10 preview, he...

By now probably everybody that is connected to PHP world knows about Facebook’s HipHop.
So here are my thoughts about it.

1. This is a very cool and exciting technology. There were multiple attempts to do this in various ways, and from what it looks, HipHop is the most successful and appealing. I know doing these things is not easy – I tried something like that myself somewhere back in 2006 but was unable to go past very basic examples (I also made a mistake of choosing C instead of C++ as target, which I now think was not a smart decision). And the progress and support for almost all of the PHP magic is definitely great. There still are unsupported areas, but mostly are dark corners into which not many people venture (or should venture, at least

2. I do not see it as a replacement for php.net code or Zend Engine. The mainstream of PHP development still happens in the community around php.net and I do not think it is going to change anytime soon. I also see the fact that HipHop engine basically re-implements all the extensions as a serious disadvantage, for which the solution should be sought, even though I completely understand the technical reasons for doing so. I do not know which kind of the solution but while for the company like Facebook it might be OK to “freeze” certain set of extensions and features and maybe catch up periodically, I think it is obvious how such model can be a problem for the wider adoption.

3. If we talk about broader adoption of this technology in a wider PHP world, there are some serious challenges to consider:

• Plugins: right now, you must compile your whole application. However, many real-life applications have extensive plugin models, which consist of their main competitive advantage – take WordPress, Drupal, Magento, any Zend Framework app – all of these allow to write custom plugins and run them alongside the main code base. The model in which you have to rebuild whole application each time you add/change a line of code is not acceptable in these circumstances.
• Modularity: this is connected to the above, but is a bit different. PHP right now runs on Apache, IIS, Lighty, nginx, and tons of other servers in different environments. For the use of the technology in the wide variety of environments PHP is used in, one must be able to modularize  and separate the application PHP code from the runtime and the environment.
• Portability: I tried to run a bunch of my scripts through the demo that the HipHop team was very kind to give me – and most of them experiences unsupported functions or some function didn’t work exactly as their PHP counterparts (random example: PHP’s fopen() would error out given empty first argument, while HPHP implementation would open the current directory as file. There are more such things…). Now, I admit, it would be very easy to fix them, to use different functions and they would work, but again I think it’s obvious how it can be a problem for a PHP programmer, if you are not coding targeting HipHop specifically – and especially of you use 3rd-party code. Having different implementations always presents portability challenges.
• Thread-safety: A huge problem with PHP thread-safety is third-party libraries. Many of them are not thread safe either explicitly, or, even worse, implicitly – i.e. they just have either bugs or information leaks between threads (like changing some setting in one thread and feeling its effect in another – imagine chdir() leaking through the thread boundaries – see how it can be a problem?) HipHop team’s answer to this question was “we had fixed all those extensions” – which, without diminishing the capabilities of this excellent team, I think is not a satisfactory answer. It very well may be that they indeed fixed all the problems they could see in the code they run – but let us not forget they run one (albeit huge) application. I have hard time believing they have fixed every threading problem with every C library in existence that has interface to PHP and will continue to do so as long as C libraries exist. This of course goes back to modularity question, since here we have coupling between compiling and runtime model.
• Debugging: obviously, debugging C++ code is orders of magnitude harder than PHP code. So you either need ninja debugging skills, or a very good set of tools to allow you to identify a problem in a live server running non-source PHP.

4. I also see certain danger potential in the success of this project. The danger primary being that the performan

Truncated by Planet PHP, read more at the original (another 2916 bytes)

Well we all have read the announcement and chatted, twittered or whatever about it. I agree thats its cool this is being open sourced. I do fear however this means that there is no one less company looking after APC (mainly leaving just Yahoo then?). For now I think this is mainly interesting for "researchers" willing to work on improving the compatibility and more importantly the workflow around HipHop. I do not expect that anyone can really get a meaningful return on investment who makes this their business anytime soon (unless they can sell people on the hype), besides FB of course.

Overall I am not so impressed with the numbers. Even a 50% speed gain across the board .. what does that really mean? Lets say Facebook spends one third of the request (and I expect this to be even lower) on network and disk I/O, then this means that they managed a performance increase by a factor of 4 in the pure PHP processing parts. Note that I talked to some of the guys at the presentation and they said that the noted 50% speed up was not a result of switching the webserver (the binary generated by way of the C++ transformation includes a multi threaded webserver).

This is of course a nice speedup but wouldn't we expect at least a 2 fold .. or more increase if we could transform our PHP code into a C extension? This approach seems a lot more feasible for the masses. Like we could just drop in a ext/symfony or ext/ZF and thanks to autoloading magic our setup would continue to run unchanged. While it might not get that 4 fold speed up .. I would be willing to wager that it would get a 2-3 speed increase in the pure PHP processing.

So again I welcome any company open sourcing stuff that solved real world problems, especially if they are also willing to support the community in understanding their solution. But to me this solution will only matter for the ultra large companies where every single percent of saved CPU cycles matter. For the rest of us I think we need to rely on APC for a bit longer. But maybe with this transformator out there, other people will start working on the much more feasible approach of writing a PHP Code to C extension transformator.

A lot has already be speculated about what percentage of existing PHP users would benefit from using HipHop. The numbers seem to range somwhere between 0% and 100%. I will not try a guess myself, but rather try to shed some light on some the most important prerequisites I think there are for a company to benefit from HipHop.

By now, you might have heard the details of HipHop, Facebook’s PHP-to-C++ convertor that was announced yesterday. Like most of you, I’m eagerly awaiting the release of the code so that I can play with it and learn in detail what it can do and what it can’t. For now, Marco’s post seems to have the most technical information in it so far.

I’m with Sebastian on this one. Whether or not you think Facebook’s HipHop is relevant to you, I think they deserve credit for having shared their particular solution with the wider community. (They’ll get extra credit when they actually release some code ) After all, they’ve built on top of open-source in the first place; giving something back to the community is part and parcel of being a good member of the community.

How many of you earn your living from open-source, but have never contributed anything back?

But that isn’t really what I want to blog about today.

I’ve been following the chat on Twitter about HipHop, and I think all the nay sayers have been overlooking an important point. HipHop has the potential to reduce the amount of power consumed in running a website. And surely that can only be a good thing for all of us?

If you don’t run your own servers in a data centre (for example you use a virtual server, or host on a shared hosting solution), then perhaps you might not be aware that the power required by each server in a rack is often a major factor in the overall cost of running the servers. Whether or not you believe in climate change, energy prices are on the rise. Whether or not you believe in peak oil, oil and natural gas supply issues are forecast to push energy prices up further. Taking steps to get more work done per unit of power consumed has been the focus of hardware manufacturers for several years now. Isn’t it time it also was the focus of the software community too?

CPU usage is only one aspect of the total power consumed by a server in a rack, but in my experience people tend to add more servers to their solution primarily because they need more CPUs running their web servers to handle more traffic. A reduction in the number of CPUs required will translate into a reduction of the number of servers required … which means a reduction in the amount of energy being consumed.

How can that not be a good thing, if it can be achieved?

I know the answer will be that PHP apps are not CPU-bound, that they spend much of their time waiting for results from the database. That might be true if you’re measuring a PHP app from the point of view of elapsed time, but what if you’re measuring the PHP app in terms of CPU cycles consumed? Every single PHP script has to run on a CPU, and has to get to the point where it’s sat waiting for the database. If HipHop means that each PHP script uses less CPU to get to the same point, that has to be a step in the right direction.

Until we can play with HipHop ourselves, it’s impossible to say whether it saves enough CPU cycles to allow us to use less CPUs and therefore less servers. Remember, you’ve still got the overhead of your operating system and web server to factor into the equation. And then there’s the energy cost of compiling your code in the first place during development; for seldom-visited websites, HipHop may increase overall energy requirements.

But it sure is nice to hope, isn’t it?

Disclosure: Since Facebook Inc. is a customer of thePHP.cc, I might be considered biased. For the purpose of this blog posting, consider me taking off my "thePHP.cc hat" and putting on my "PHP Community hat".

The Announcement

Yesterday Facebook Inc. announced "HipHop for PHP", a source code transformer that turns PHP 5.2 code (minus some features) into C++ code that can then be compiled with g++, for instance, to a regular binary.

The Summit

If you are following some key PHP community members on Twitter, you may have learned that a couple of weeks ago Facebook invited a select few to Palo Alto, CA to give them a sneak peek at the technology.

Terry Chay has a great summary of this event (including photos):

At the Summit
Facebook, Palo Alto, California

This "private summit" is one of the reasons why this announcement was preceded with a lot of rumors. I am not really interested in rumors (or conspiracy theories, for that matter), so I will focus on the technology and its impact here.

My Opinion

I am very happy — both as a "programming language geek" as well as an Open Source enthusiast — that Facebook Inc. decided to open source their solution to their problem. Understanding this is crucial:

• Facebook had a problem.
• Facebook found a solution for their problem.
• Facebook decided to share their solution with the PHP community at large.
  Kudos for that!

Now what was their problem?

Facebook has a large code base that would take a long time (one to two years by my estimation) to refactor or rewrite in either PHP or another programming language to achieve the performance improvement that Facebook was looking for. During this time of refactoring or rewriting, Facebook would not have been able to innovate.

In the past, Facebook tried to achieve performance improvements by contributing to PHP as well as APC. Many PHP deployments benefit from this contributions today, but for Facebook they were simply not enough.

From this perspective it makes a lot of sense to dramatically change the way that they deploy and execute their PHP code: without major modifications to their existing code base they are able to run it with a CPU usage reduced by 50%:

"Facebook sees about a 50% reduction in CPU usage when serving equal amounts of Web traffic when compared to Apache and PHP.

Facebook's API tier can serve twice the traffic using 30% less CPU."

This is a sustainable solution for them as it allows them to benefit from PHP's advantages such as shorter development cycles and lower training costs — while at the same time, thanks to HipHop, reducing their data center costs.

What others are saying ...

Terry Chay is spot on when he summarizes the impact of HipHop in his blog posting:

"Arguing against PHP for performance reasons no longer holds water. [...]

In practice, you can get the advantages of having a scripting language without operational costs. [...]

HipHop is a showcase. With it the PHP world can point to Facebook as being the busiest site built in a scripting language in the world."

Stefan Priebsch (also with thePHP.cc) makes the point that you need to rethink your PHP development before you can dance to the HipHop beat:

"HipHop executes PHP code bypassing the Zend Engine, so there is no guarantee that a program will behave exactly alike on PHP and HipHop. More and better automated unit and integration tests will be required to allow you to compare the results on PHP and on HipHop, and determine whether deviations are to be interpreted as a bug, or can be tolerated."

I could not agree more: As there is a real build — including a real compilation — with HipHop, best practices such as coding standards and continuous integration will be even more important.

In conclusion, I would like to welcome "HipHop for PHP" to the PHP ecosystem. Yes, it is not a solution for a problem faced by 99.9% of the PHP deployments out there. But this does not make it less interesting in any way.

One more thing ...

PHPUnit runs on "HipHop for PHP", details can be found in the wiki.

My apologies to Ron Burgundy for the title of the post, but I’m just a fan of the wisest man to ever live.

It’s not for you.

You, being the average PHP developer, systems administrator, hacker.  A lot is being made of how CPU load went down by 50% etc, that’s a great number and on the surface very hard to argue with, but to really understand it, you must understand the problem a lot better. Facebook didn’t decide to write HipHop and use it in production because they had all this money laying around and felt like paying 3 engineers to work on something. They looked at other existing alternatives, implemented them, and when they maxed them out, decided to switch.

HipHop Does Not:

If anything, HipHop should be your last resort.

But, it’ll help me reduce the number of web heads!