Facebook Rewrites PHP Runtime For Speed

VonGuard writes "Facebook has gotten fed up with the speed of PHP. The company has been working on a skunkworks project to rewrite the PHP runtime, and on Tuesday of this week, they will be announcing the availability of their new PHP runtime as an open source project. The rumor around this began last week when the Facebook team invited some of the core PHP contributors to their campus to discuss some new open source project. I've written up everything I know about this story on the SD Times Blog."

Comments

is this being used now?

[Anonymous Coward]

Is this what they're using on the newly redesigned site? Because if so, it's pathetically slow. Facebook is one of those places that with every attempt to "improve" things somehow manages to make it worse and worse. They're a perfect candidate for a Microsoft buyout.

Re:is this being used now?

[Daengbo]

Try the "Lite" version. It's much faster, and doesn't have that annoying chat bar.

Screw PHP, I write everything in C

[Anonymous Coward]

PHP is for lazy developers. I develop my webapps in C and I even wrote my own httpd to improve performance.

Re:Screw PHP, I write everything in C

[biryokumaru]

C is for lazy developers. I develop my webapps in JWASM and I even wrote my own httpd to improve performance.

Re:Screw PHP, I write everything in C

[eclectro]

I develop my webapps in C and I even wrote my own httpd to improve performance.

C is for lazy coders if you ask me. I hand code and tune assembly language programs on an altair 8800 flipping switches on the front panel. As all real programmers should do.

Re:Screw PHP, I write everything in C

[sopssa]

JWASM is for lazy developers. I develop my webapps in machine code and I even wrote my own internet to improve performance.

Re:Screw PHP, I write everything in C

[biryokumaru]

Servers are for lazy developers. I develop my webapps in my head and I even deliver the pages manually to improve performance.

Re:Screw PHP, I write everything in C

[deniable]

Excuse me, I'm still waiting for the last page and it's almost bed time.

Re:Screw PHP, I write everything in C

[Anonymous Coward]

Webapps are for lazy developers. I sip my coffee, causing a multiply entangled photon to collapse and resolve the location of countless electrons throughout the universe, spurring various exotic species of butterflies to flap their wings a twitch differently, which in turn subtly alters the flow of the viscid gaseous matter in Earth and various other planets, affecting the touch organs of living matter that can feel moving fluid, which messenger or nervous impulses relay to their minds, creating customer-tailored web content for my clients.

Re:Screw PHP, I write everything in C

[Galactic Dominator]

I don't know why this has not yet been linked

Just taking a shot in the dark here, but I'll attempt an answer. The reason no one else linked to it is because you're the only one who considers it obligatory. Slashdot regulars will know that this type of thread happens on a near daily basis and with all due respect to xkcd there is simply no need to make another tired attempt at karma whoring.

Re:Screw PHP, I write everything in C

[BRSQUIRRL]

Steve Gibson, is that you? :)

Re:Screw PHP, I write everything in C

[rpetre]

I'd like to point out that long before xkcd there was userfriendly, and that in my circle we still like to and this sort of joke by saying "magnets" and giggle. The "Edward Lorenz, the butterfly and the chaos theory" punchline seems a bit forced (unless you go for the 'M-x butterfly' twist to make the emacs guy get the attention ;) )

Re:Screw PHP, I write everything in C

[S.O.B.]

Nice try. I rewrote the universe to include php and httpd in the kernel.

Reboot in 3...2...

High performance in scripting languages?

[BadAnalogyGuy]

At some point, if you are lucky enough, you will require extremely high performance from your web pages. You start out coding HTML in Notepad and move on to Perl CGI then on to PHP with scripting embedded right in the generated HTML. All the time you gain programming crutches at the expense of processing speed, and for a while this is a great tradeoff.

But one day you start having server hiccups because your scripts can't keep up with your traffic. Sites like Amazon have already run into this and have moved away from scripting languages and back to system languages. Running applications directly on the CPU instead of relying on a runtime to translate (at best) bytecode into machine instructions means maximizing CPU cycles.

So I wonder what longterm benefit there is in improving the language runtime.

Re:High performance in scripting languages?

[sakdoctor]

1. Static HTML
2. PHP
3. ???
4. Rewrite the PHP runtime

Truth is, that step 3 involves a whole load of steps where 90% of the problem will be database bound. Complied languages are not going to the magic solution in a real world situation.

Re:High performance in scripting languages?

[sopssa]

Exactly, and it's not like there is so much heavy processing cpu wise. Facebook probably has calculated that they can get enough performance out of recoding the runtime (even 1% is large enough for site as large as facebook). While doing that they also create a faster runtime that everyone can use. Everyone moving to write their sites in C/C++ doesn't make any sense.

Also a lot of the site structure can be cached in memcache or accelerating proxies like squid, so you aren't actually interpreting PHP code lots of the time. Facebook also did a lot of work towards memcache, because they are mostly a DB heavy site, not CPU.

Re:High performance in scripting languages?

[gbjbaanb]

Complied languages are not going to the magic solution in a real world situation.

whilst that's perfectly true, its only true to a point. Lots of people run eaccelerator or apc on their PHP sites, simply to improve performance. If these pre-compile caches didn't do anything for performance then you'd be totally right, but as they do, you've got to appreciate that replacing the PHP with a compiled language will make a significant difference.

as always, don't guess where performance problems live, measure them. Often you'll be surprised, especially as load increases.

Re:High performance in scripting languages?

[amn108]

Check your facts better next time please.

PHP does not have to execute scripts from scratch on every request. APC cache API transparently caches JIT-compiled PHP script intepretations and these are run instead upon request.

Apache does not have to compile regular expression for mapping each URL request, when you specify RewriteRule directives in virtual server or server context it compiles them (or however else it wishes to cache these) on server startup and that is it. During the entire lifetime of the server, the specified rules are no longer interpreted.

Other than that I agree that the current style of server infrastructure we are "enjoying" can be improved at least 100-fold, database access including.

* Truly persistent (across HTTP requests) user memory is a good step in the right way - extend the lifetime of all scripted objects to persist across entire application lifetime (i.e. forever - servers are not supposed to die)

* Many database requests are so primitive that these could bypass TCP socket layer and benefit from extra speed at the cost of no longer being asynchronious. Most PHP developers use blocking database query APIs anyway, even though non-blocking calls are available.

* Compile scripts and run from compiled cache, preferrably as machine code. Think about environment - all those quad-core datacenters wasting cycles, because programmers are supposedly very expensive. Well, they are not that expensive that when a good team get together they cannot re-think this. They can. If nothing, they should worry about the environment too - it is not cheap.

* Offer asynchronious calls where these make sense (i.e. where they can benefit from hardware parallelization). Those devs who know how to make use of them will be happy to do speed up their applications.

In short, cache everything, whenever you can. Memory is cheap. Cache SQL query strings, cache script compilation output, cache, cache, cache.

Re:High performance in scripting languages?

[Lennie]

Facebook added to memcache the ability to use UDP instead of TCP. They also changed MySQL so one replication-command from one datacenter to the next would also invalidate what is in memcache on that location.

At some point they have so much traffic from their webservers to their backendsystems, they saturated their internal network and were dropping UDP.

That's the kind of problems/scale they deal with, I'm surprised PHP wasn't their biggest bottleneck before (they did some work on PHP already, but not something like this).

After all Facebook is the second site after www.google.com-search page (which handles 'just' one task) and Google has pretty much a custom-build platform.

Assembler is High Performance

[Murdoch5]

Don't starting talking about high performance and then naming languages that don't have the chance to deliver. What you really need to do is just program the entire web page in Assembler and then your going to have speed and performance that can't get any faster. If your developers are noobs and can't use real languages and there just Object Oriented kids who can't work on memory and need to access everything through abstracted methods, then fire them and get in some embedded developer who know speed = good code and good languages. If you don't want to use assembler then use good old C!

You want speed use languages that can deliver and don't try to rewrite slow scripting languages to do the job of the trusted old methods, assembler and C.

Re:Assembler is High Performance

[erroneus]

Actually, that isn't necessarily true. It might be true in a linear sense, but when it comes to juggling different threads and the like, assembly language as I knew it wasn't all that capable of describing the process all that well. Assembly language is a go-cart with rocket boosters.

I would truly like to see an assembly language revival though. I truly would. It would be a return to sensibilities in programming. It would be a return to being careful with memory usage with improved focus on small efficient programming. It would be a really good thing. I just don't see it happening.

The purpose for these more complex languages is about being able to more symbolically describe the processes to be executed by the machine. Assembly language was some of the worst about that -- if there wasn't a very detailed set of comments for nearly every line of code, it would be nearly impossible to follow in source. These more complex languages will always have their place and purpose. Trying to make them more efficient is a good and useful thing. Now if we were talking about writing the PHP interpreter in assembler, I'd say you had a winner compromise.

Re:Assembler is High Performance

[javacowboy]

I'm a Java developer with 10 years of experience developing enterprise grade server applications. We use Java, like the majority of Fortune 500 companies, because a Java app can be maintained with a development team greater than 1 coder, common memory coding errors and behaviours is avoided, a large API library prevents us from having to re-invent the wheel constantly, and the JVM is battle-tested in large deployments.

But, no, I guess I'm just a kid who doesn't know how to code.

So is it a fork or isn't it?

[erroneus]

Sounds like Facebook rewrote PHP and then invited PHP core developers to adopt it as their core development platform? I can't imagine that went over all that well... probably hit a number of them in the pride region. And the article said it is to be released as open source, but failed to mention the license. Will this be some sort of twisted "FriendFace Public License" or some perversion?

This is not what is meant when a party contributes to an open source project. "Here, I rewrote it for you. It's better. Now just throw away everything else you've done and use this." Really?

HyperPHP, or HPHP

[hkz]

According to that article posted recently about Facebook's master password being 'Chuck Norris', the project is indeed a compiled PHP that goes by the name of HyperPHP, or HPHP. It will supposedly lower the load on the servers by 80% and speed up things 5x, according to the unnamed source in the original blog post.

Misleading Summary (surprise!)

[Anonymous Coward]

From TFA: UPDATE: After sifting through the comments here and elsewhere, I'm inclined to agree with the folks who are saying that Facebook will be introducing some sort of compiler for PHP.

Not a fork. Not as newsworthy as implied.

Was revealed 3 weeks ago by insider

[diretalk]

This PHP compiler item was revealed three weeks ago by a Facebook employee. Read at http://therumpus.net/2010/01/conversations-about-the-internet-5-anonymous-facebook-employee/?full=yes

One man effort

[hey]

So there is one guy at Facebook doing this PHP rewrite. It must be possible to figure out who he is. Have they hired any high profile PHP developers?

Three sources of scripting language inefficiency

[tepples]

I don't know what the fascination is with scripting languages on the Linux platform or with FOSS in general, but it results in slow programs

Speed of development is faster in a scripting language, and in developed countries, below a certain scale, throwing hardware at it is cheaper than throwing programmers at it. The point of the article is that Facebook is above that scale, and programmers to write a new PHP interpreter have become cheaper than adding hardware+power+cooling.

with flaky UIs.

Citation needed. True, the often use a different widget set from the rest of the desktop (e.g. Tk from Tcl and Python and Swing from Java), but the popular widget sets also have scripting language bindings. how can one really tell the difference between a wxWidgets or GTK app written with Python vs. C++?

I like to use refurbished/recycled machines; which means that I'll have an old P4, 512M RAM and a slow bus.

Do these use more electric power than, say, an Acer Aspire Revo? The power consumption of a Pentium 4 and the power to remove the heat it generates can become an issue, especially for a server that's turned on 24/7.

Many times, applications written in a scripting language, whether it be Perl, Python, PHP, or whatever, will hang often and then start working.

There are three causes for this, and you can distinguish them with 'top' or 'Task Manager' or something else that can count CPU time and page file accesses:

• Swapping: More dynamic languages tend to use more general data types, which incur memory overhead. For instance, they might use UTF-16 strings instead of 8-bit strings with an assumed encoding. Or they might use double-precision floating point instead of short integers for large arrays. This might cause a program to run out of RAM and fail over to the disk more often.
• Garbage collection: This covers ways of determining which resources are no longer in use by any active part of the program. Python, Objective-C, and lately C++ primarily use an incremental garbage collection method called reference counting, which keeps track of the number of things that "know about" an object. But some other language interpreters use only tracing garbage collection, which in the naive form causes the application to pause and make a list of all live objects once memory allocations exceed some amount. This will cause a CPU spike.
• Blocking: A lot of the APIs available to programs in scripting languages don't have well-known non-blocking versions. For example, a host name lookup might freeze the program until it finishes. The only way to work around these is to start a thread. This will cause a pause with 0 CPU and 0 disk.

PHP is slow (check), now what....

[Ritz_Just_Ritz]

Why not just stash your farm of slow php systems behind some heavy duty caching appliance(s)?

Something like aicache might fit the bill.

Re:PHP is slow (check), now what....

[jimicus]

Why not just stash your farm of slow php systems behind some heavy duty caching appliance(s)?

Something like aicache might fit the bill.

When your application is with each iteration generating more content dynamically than it was before (and you want to continue down that route), the benefit of caching starts to drop quite quickly.

Complexity and cost of embedded approach

[tepples]

If your developers are noobs and can't use real languages and there just Object Oriented kids who can't work on memory and need to access everything through abstracted methods, then fire them and get in some embedded developer

Embedded developers tend to 1. work on smaller, more focused systems, and 2. charge more. For one thing, a module inside Facebook deals with data types more complex than those in the firmware of a car engine's microcontroller. And below a certain scale, the money you save by hiring noobs (and taking the tax credit for recent graduates if available) can pay for throwing more hardware at the problem.

Re:Complexity and cost of embedded approach

[CptPicard]

true, but on the other hand most of what I've seen is that the embedded developers can program the higher level languages with more care anyway

My impression tends to be that the best overall programmers are those with a solid understanding of algorithmics theory, programming language design in general (meaning they have had exposure to all kinds of solutions), and most interestingly, tend to have an understanding of functional programming. The true programmer gods I have come across have always been Lispers, almost without exception.

On the other hand, I never understood what is supposedly so educational and intellectually important in things like assembly. If one only learned that, it wouldn't still mean that one could actually use it for anything... it's just "manipulate state in registers and RAM by making use of extremely rudimentary basic operations". The transformations into machine code from higher-level program solution descriptions are much more consistently handled by a compiler than a human, and as that is manual, automatable work, it may be more important to study compiler construction... (which Lisp is pretty good for)

Assembler? Really?

[Atmchicago]

Assembly language isn't platform-independent. It's really easy to screw up and hard to optimize. And it's not much faster than C/C++. The issue at hand is balancing the cost of writing the code with the cost of running it. I don't see how the cost of writing and maintaining software in assembly language will ever compete with the costs of C/C++, potential speed increases and all. Object-oriented languages make small performance sacrifices in return for much greater maintenance, and that's how it should be. Scripting languages take this even further, and for these large websites have lost their advantage. The only time assembly will prevail is when we return to incredible memory constraints, but even embedded systems pack tons of memory now so I don't see that being an issue.

Re:Is compiled PHP even possible?

[BadAnalogyGuy]

http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/

Worth a look.

Re:Facebook's architecture is the problem, not PHP

[pmontra]

I'm no PHP fan but I won't be surprised if FB decided that optimizing the interpreter and investing resources in new functionality is a better business decision than investing in a giant rewrite of what they have now. That would effectively stop them for many months in the best case, or double their costs as a team keeps adding features to the PHP architecture and another one plays catch-up in another language. But maybe they also have some plan to rewrite some core components in a faster language, like twitter did porting the backend tasks from Ruby to Scala.

We could say that they started with the wrong technology but using PHP Zuckerberg was able to deliver what turned out to be a successful product back in 2004. Had he wrote it in Java he could have missed a window of opportunity and people could be using some different social network now. Same logic applies to twitter's choice of Ruby, which by the way they still use for the frontend. Many recent interpreted languages (I'm thinking about Ruby) trade execution speed for speed of coding and delivering products. Many products totally fail and many others don't get so successful to need optimizations so IMHO speed of delivery is the key factor: deliver, get customers, get money and only then we'll think about making our servers run fast.

Ah... If only FB's new interpreter could access instance variables without that redundant $this-> construct that clutters all OO PHP code...

JavaScript

[tepples]

Flaky UIs - click on a button and nothing happens. Or things not drawing properly.

I've seen buttons do nothing and redraws fail even in compiled programs.

A refurb machine is about a third the cost of a new machine

By "cost", do you include or exclude the cost of power and cooling? And do you include or exclude the cost of replacing failed components? Capacitors die.

scripting languages are not appropriate for large applications with GUIs.

One scripting language has a huge deployment advantage over everything else: ECMAScript. It interacts with Document Object Models exposed by various runtime environments, and it's sandboxed so that users can more or less safely run a program without getting an administrator to install it. You might know it as JavaScript (ECMAScript + HTML DOM) or ActionScript (ECMAScript + SWF DOM). Or would you rather go back to ActiveX, where the web site sends the equivalent of a compiled DLL to each user, which runs with the user's full privileges and doesn't run on anything but a convicted monopolist's operating system?

Re:JavaScript

[drinkypoo]

One scripting language has a huge deployment advantage over everything else: ECMAScript.

This is a nice lead-in to my point, though; Facebook is one of those websites that make it look like Firefox is murdering your machine. In reality, it's sites which misuse Javascript. (Sorry, but ECMAScript is just too unwieldy. I wouldn't say it. Too bad, because it desperately needs renaming.) If I leave Slashdot open all night, nothing bad happens. If I leave a long Facebook tab open all night, I have to close it before I can use my browser in the morning, even on my shiny new 4GB RAM system, let alone on my 1GB machines. If they want to improve the user experience, they should try cleaning up their crap Javascript.

They should spend more on the upload tool

[crossmr]

That thing is a broken buggy piece of garbage. Any time I go out to an event or something and want to upload anything more than half a dozen photos, it inevitably blows up on random photos for no reason (completely fresh off the camera unedited photos). I have to babysit the upload and instead of just hitting select all and letting it go, I end up having to upload it in chunks of 5 photos at a time.

Re:They should spend more on the upload tool

[stimpleton]

Modern users demand upload progress feedback. Which the HTML spec cannot do. The solution is a bevy of hoary hacks on the server end, usually by using a cache or tmp file callback. The value is then read periodically from the client as a javascript page load in an iframe.

For PHP this is the APC Cache module. You send an id with your file upload form then "Load that page using that ID" till the progress gets to 100%. According to the docs the module can poll at a period of "0 seconds" meaning as fast as possible. This halves upload speed.

On the client end, the old HTML way(no feedback) was a simple form with a submitted page. If you arrive at the submit page then the upload worked. The new way is 50-60k of javascript, which is a collection of fragile code. Yahoo's GUI upload for example. Try moding their code and your GUI *will* fail. The file may or may not upload.
br Given the modern web is *all about* uploading user submitted media, I am amazed there arent headlines "Mozilla forgets everything and rebuilds file upload in partnership with Apache...then thinks about HTML 5"

Re:They should spend more on the upload tool

[raju1kabir]

Just scale your photos down to 1024x768

Scale your photos down to 604x453, which is the size Facebook displays them at, and you will get to control the sharpness and image quality.

Upload at any other size, and Facebook will re-sample them with some very cheap algorithm and apply aggressive compression and they will look like ass.

Try it, you'll be amazed how much better your photos suddenly look.

I normally use "convert -strip -sharpen 0.3 -quality 85 -geometry 604x604" before uploading - it just takes a second, and makes a huge difference.

Resin Quercus

[parryFromIndia]

Caucho Resin has a mostly pluggable replacement for PHP which is written in Java. It adds web friendly features to PHP like distributed sessions and load balancing. Given the JVM JIT is already plenty fast and the benchmarks show that Java/PHP beats regular PHP handily - I wonder if Facebook considered using it at some point.

Re:Resin Quercus

[parryFromIndia]

Here is the URL in case people are interested in checking this out - http://www.caucho.com/resin-4.0/doc/quercus.xtp .
In summary:
It is OpenSource, 100% Java and it brings all the advantages of using a JVM to PHP - performance (JIT), Safety, Scalability (clustering/load balancing), quality tools (Development, Profilers). One can use most of the Java technologies in PHP to ease development even further - XA Transactions, JNDI, Connection pooling, object caching for example.

Besides, improving performance of this pure Java PHP implementation ought to be easier than improving the PHP runtime. (Java6 onwards the available tools to debug and optimize Java applications have made significant progress. jmap/jhat , easy heap dumps on OutOfMemory, Object Query Language etc. already come bundled with the JVM and then there are Eclipse and NetBeans GUI profilers.)

Also worth checking out Dr. Cliff Click's extensive Java vs. C performance blog post - http://blogs.azulsystems.com/cliff/2009/09/java-vs-c-performance-again.html .

Akamai sucks

[Turmoyl]

If Facebook really wants to speed up the customer experience all they need to do is remove Akamai from their content delivery network (CDN). That's where my browser is always stuck in a Waiting status when I notice a connectivity issue.

Re:"Java" and ".Net" as an inspiration? No, thank

[Abcd1234]

Speed of "Java" and ".Net"? Is it a joke?

No, it's not.

"Java" hangs all the time

No it doesn't.

and the ".Net" code to do a simple task is so convoluted that it is just ridiculous.

No, it's not.

Honestly, you really have no fucking clue what you're talking about, do you?