Forgot your password?
typodupeerror
PHP Programming Social Networks

Facebook Rewrites PHP Runtime For Speed 295

Posted by timothy
from the if-not-this-then-something-else dept.
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."
This discussion has been archived. No new comments can be posted.

Facebook Rewrites PHP Runtime For Speed

Comments Filter:
  • by Anonymous Coward on Sunday January 31, 2010 @09:40AM (#30969930)

    It's not just websites. 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 with flaky UIs.

    I like to use refurbished/recycled machines; which means that I'll have an old P4, 512M RAM and a slow bus. Many times, applications written in a scripting language, whether it be Perl, Python, PHP, or whatever, will hang often and then start working. I can always tell. That's why I knew Open Office was written in something like C when others on the Net were stating it was written in some such interpreted language.

  • HyperPHP, or HPHP (Score:5, Interesting)

    by hkz (1266066) on Sunday January 31, 2010 @09:42AM (#30969940)

    According to that article posted recently [slashdot.org] 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.

  • VM's (Score:2, Interesting)

    by MattBD (1157291) on Sunday January 31, 2010 @09:54AM (#30969996) Homepage
    Would a language that runs in a VM, like Java, Scala or C#, be faster? After all, Twitter rewrote their backend in Scala and they seem to have gotten better performance.
  • by sopssa (1498795) * <sopssa@email.com> on Sunday January 31, 2010 @10:01AM (#30970024) Journal

    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.

  • by Ritz_Just_Ritz (883997) on Sunday January 31, 2010 @10:08AM (#30970062)

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

    Something like aicache might fit the bill.

  • by tepples (727027) <tepples&gmail,com> on Sunday January 31, 2010 @10:09AM (#30970072) Homepage Journal

    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.

  • Assembler? Really? (Score:5, Interesting)

    by Atmchicago (555403) on Sunday January 31, 2010 @10:11AM (#30970080) Homepage
    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.
  • by Anonymous Coward on Sunday January 31, 2010 @10:22AM (#30970138)

    You are kind of person I would never hire. Period.
    Assembly doesn't mean speed. there is only potential not more. It has become increasingly difficult to develop in assembly as the architecture and complexities involved (drivers, APIs, hardware, devices, underlying os, etc.) has evolved so much. Decent optimizing compilers nowadays out perform hand written assembly. Further more in commercial software development time is pretty much the most important factor. If you could do in 1 day same thing that would take 2 weeks with assembly? The choice is clear. Not to mention concerns about portability, maintainability, extendibility, ..

    So really everything considered you should seriously rethink your ideals about developers because any seriously minded person just laughs at statements like yours.

    Sorry, but true.

  • by pmontra (738736) on Sunday January 31, 2010 @10:45AM (#30970276) Homepage

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

  • by crossmr (957846) on Sunday January 31, 2010 @11:23AM (#30970520) Journal

    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:JavaScript (Score:4, Interesting)

    by drinkypoo (153816) <martin.espinoza@gmail.com> on Sunday January 31, 2010 @11:38AM (#30970612) Homepage Journal

    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.

  • by CptPicard (680154) on Sunday January 31, 2010 @11:40AM (#30970624)

    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)

  • Resin Quercus (Score:4, Interesting)

    by parryFromIndia (687708) on Sunday January 31, 2010 @11:40AM (#30970626)
    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.
  • Akamai sucks (Score:3, Interesting)

    by Turmoyl (958221) on Sunday January 31, 2010 @11:42AM (#30970634)
    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.
  • by stimpleton (732392) on Sunday January 31, 2010 @01:55PM (#30971672)
    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"
  • by Eil (82413) on Sunday January 31, 2010 @04:40PM (#30973374) Homepage Journal

    What you call a crutch, most developers call an enormous time saver. The web moves so fast that you simply cannot afford to take forever developing it just so that the code executes efficiently. Sure, PHP, Perl, Python, and Ruby are slower than C or C++. But for at least the last decade, hardware has been cheap enough that it makes a lot more business sense to just throw more servers at the problem than it does to delay your product launch for a year and/or double your programming staff while you make everything "perfect" in a lower-level language. Most of the problems around making web apps scalable to millions of concurrent users have been solved or will be in the near future. (CDNs, memcache, load balancers, etc.) When you find bottlenecks, you rewrite those specific parts using a better design or a lower-level language. If your developers are any good, they will have modularized the code, making such upgrades relatively painless. Trying to optimize the entire codebase for performance before it's even out in the wild ensures that it will never get there.

A failure will not appear until a unit has passed final inspection.

Working...