Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
PHP Programming Social Networks

Facebook Rewrites PHP Runtime For Speed 295

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 @08:15AM (#30969806)
    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.
    • by Daengbo ( 523424 ) <{moc.liamg} {ta} {obgnead}> on Sunday January 31, 2010 @08:27AM (#30969866) Homepage Journal

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

      • I was using touch.facebook.com on my N800, but I like the look/feel of this better.

        Thanks!

      • I have to agree fully here. The lite version is missing some things that I like but I can live without them for the speed tradeoff. Only problem I have is that the toolbar for Firefox only points at the main site, otherwise it keeps the bloat way down.
        • by pvera ( 250260 )

          After using it for a few minutes I got a link to a preference that makes lite the default site. And you have the option to keep a bar on top of the screen that lets you toggle between the two sites.

    • Re: (Score:3, Informative)

      by rel4x ( 783238 )
      Facebook has a few problems. Overuse of ajax combined with this absolutely bizarre habit of including dynamic javascript at random points in the script. These lead to slower runtimes, especially with older browsers where (upon encountering a JS file) they completely stop doing everything else to execute it.
  • by Anonymous Coward on Sunday January 31, 2010 @08:18AM (#30969824)

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

  • by BadAnalogyGuy ( 945258 ) <BadAnalogyGuy@gmail.com> on Sunday January 31, 2010 @08:23AM (#30969846)

    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.

    • by sakdoctor ( 1087155 ) on Sunday January 31, 2010 @08:39AM (#30969922) Homepage

      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.

      • by sopssa ( 1498795 ) * <sopssa@email.com> on Sunday January 31, 2010 @09: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 gbjbaanb ( 229885 ) on Sunday January 31, 2010 @09:37AM (#30970228)

        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.

    • by CAIMLAS ( 41445 )

      My understanding is that one of the major problems with PHP for something like facebook - as opposed to a language like Perl or Python - is that unlike other languages, PHP does not manage SQL database session connections. This results in those professional "oops, we fucked up" messages, timeouts, and other fun stuff like that which wouldn't happen (as regularly) if they'd designed things well.

      So if they're fixing that in their PHP rewrite, I'd say they're fixing half the problem they've got. The other half

    • Re: (Score:3, Informative)

      I'm sure a lot of intensive stuff is done in a system language but Amazon still uses Perl. Google use Perl and Python through their sites.

      There's no need to to use a system language for everything. Facebook is probably using PHP on its own and that's just not wise for a site like that.
    • Re: (Score:3, Interesting)

      by Eil ( 82413 )

      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 every

  • by Murdoch5 ( 1563847 ) on Sunday January 31, 2010 @08:31AM (#30969884) Homepage
    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.
    • by erroneus ( 253617 ) on Sunday January 31, 2010 @08:49AM (#30969978) Homepage

      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.

      • I would truly like to see an assembly language revival though.

        The revival is here. It is called NESdev [nesdev.com]. It's just not for making PC programs because the processes to be executed on a PC tend to be much more complex.

        Now if we were talking about writing the PHP interpreter in assembler, I'd say you had a winner compromise.

        You'd have to do so over and over for x86, x86-64, ARM, PowerPC, and other architectures on which PHP runs. That's why these interpreters are most often written in C, with occasional reference to the assembly language code that the compiler generates. Really the only time you have to handle assembly in a PC application is when you're implementing a just in

        • Re: (Score:3, Insightful)

          by epine ( 68316 )

          Really the only time you have to handle assembly in a PC application is when you're implementing a just in time compiler, and it's becoming the fashion to let LLVM do that for you.

          That's an interesting combination of overstating and understating the case.

          For one thing, your favourite C/C++ compiler likely contains a hand optimized memcpy() routine, down to assembly if it exposes a worthwhile gain, or coded in C with or without intrinsics if it doesn't. Many C/C++ compilers contain hand-optimized floating point routines, even more so in the embedded world. Plus there are many performance libraries out there to handle the heavy lifting in multimedia, mathematics, and encryption, some

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

        by Atmchicago ( 555403 ) on Sunday January 31, 2010 @09:11AM (#30970080)
        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: (Score:3, Insightful)

          In today's modern processors you wont gain much performance in assembly. A core2duo simply reads the x86 instructions and converts them to risc and much of the optimizations happen at the compiler and during execution on the fly. You can always gain some speed but its nowhere near what it could do just a decade ago.

          What also needs to be taken into account is the costs and time to rewrite years of development work from scratch. Sunken costs drive accountants crazy and threaten the job of any IT manager.

          Inste

    • by tepples ( 727027 ) <tepples.gmail@com> on Sunday January 31, 2010 @09: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.

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      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 ta

      • If you could do in 1 day same thing that would take 2 weeks with assembly? The choice is clear.

        Unless the two weeks of hand-tweaking the assembly language code of your program's single biggest bottleneck would reduce your program's system requirements so that twice as many users can use it. Such a case is reportedly common in video game development, where the increased revenue is often worth it.

        Not to mention concerns about portability

        "Portability" has more than one meaning. There's portability of the code, or its suitability for execution in multiple environments whose hardware isn't compatible. For this, you can keep a fallback implementa

    • by neoform ( 551705 )

      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.

      Yeah, us assholes with +10 years experience developing web applications are just a bunch of "noobs" because we never needed to learn Assembler or C. Enjoy spending two weeks developing what would take me an hour.

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

      For a given amount of time, in almost all cases you can deliver a faster end program by writing in C and possibly optimizing some parts in asm, rather than writing everything in asm.

      • by TheLink ( 130905 )
        Same goes for writing in a "scripting language" and optimizing some parts in C.
        • Re: (Score:3, Insightful)

          by jc42 ( 318812 )

          I've been involved in a number of projects that were prototyped in a scripting language (usually perl or python) and then rewritten in C for performance, with the disappointing result that the C code ran slower. I've also seen the same with C -> assembly a few times.

          The explanation is fairly straightforward. The low-level-language experts (including me a few times) may have known their language well, but they'd never looked into the perl/python/cc code to learn the algorithms used there. It turned out

    • by javacowboy ( 222023 ) on Sunday January 31, 2010 @11:19AM (#30970898)

      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.

  • ...though traditional forks do not get started after "friendly" meetings. But it still sounds like one; which is not a very good thing in my opinion.

    What they (Facebook) should have done is to combine resources with the PHP folks, then later release a "new" PHP version with this new engine.

    This would be dubbed progress by the majority here.

    By the way, where are the stats that show how wanting the current PHP engine's speed still is? I want to see some serious comparison.

  • by erroneus ( 253617 ) on Sunday January 31, 2010 @08:38AM (#30969918) Homepage

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

    by hkz ( 1266066 ) on Sunday January 31, 2010 @08: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.

  • by Anonymous Coward on Sunday January 31, 2010 @08:44AM (#30969946)

    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.

    • Re: (Score:2, Informative)

      by paziek ( 1329929 )

      If thats so, then they are reinventing wheel, since there is already PHP compiler available, with is also open source: http://www.roadsend.com/home/index.php [roadsend.com]

      • by gmuslera ( 3436 )
        Maybe the round wheels don't fit well in what they are doing, how they are using PHP, as dynamic language the approach that was taken in roadsend could bump against some core practice in Facebook and thats why they must use another approach to fit into that scheme.
  • by hey ( 83763 )

    Would be nice of there was an option to compile it to say .phpc files like Python. Would be a nice thing for Perl too.

    • http://eaccelerator.net/ [eaccelerator.net]

      "eAccelerator is a free open-source PHP accelerator, optimizer, and dynamic content cache. It increases the performance of PHP scripts by caching them in their compiled state, so that the overhead of compiling is almost completely eliminated. It also optimizes scripts to speed up their execution. eAccelerator typically reduces server load and increases the speed of your PHP code by 1-10 times. "

  • by diretalk ( 1712478 ) on Sunday January 31, 2010 @08:47AM (#30969966)
    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 [therumpus.net]
    • From that article:

      PHP is an example of a scripted language. The computer or browser reads the program like a script, from top to bottom, and executes it in that order: anything you declare at the bottom cannot be referenced at the top.

      This was true in PHP3, but since PHP4, even declaring functions at the bottom of a file, they were still available at the start of a file execution. Everything got compiled in to an intermediate stage before execution.

  • One man effort (Score:4, Insightful)

    by hey ( 83763 ) on Sunday January 31, 2010 @08:47AM (#30969970) Journal

    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?

  • VM's (Score:2, Interesting)

    by MattBD ( 1157291 )
    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 Ritz_Just_Ritz ( 883997 ) on Sunday January 31, 2010 @09: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 jimicus ( 737525 ) on Sunday January 31, 2010 @09:24AM (#30970146)

      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.

    • Re: (Score:3, Insightful)

      by slim ( 1652 )

      Facebook does as much caching as it can - I mean, they're not daft. They're probably the world's greatest experts on large scale MySQL + memcached.

      But sometimes cached data isn't good enough. Facebook users expect their statuses, messages and comments to reach their friends within seconds.

  • Facebook is dependent upon a scripting language, and then Facebook complains about speed? Facebook's real problem here is their short-sightedness. Instead of putting a band-aid on the current architecture via some sort of acceleration for PHP, Facebook should re-architect their site with a structure and language that is capable of handling the current and future loads.

    .

    I am sure we will be hearing all about how successful this project is, but is the auccessful application of a band-aid really the long-t

    • If you read the article, it sounds like it might be more than just an accelerator.

    • by pmontra ( 738736 ) on Sunday January 31, 2010 @09: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...

    • Re: (Score:3, Insightful)

      by kobaz ( 107760 )

      Instead of putting a band-aid on the current architecture

      But that's exactly how you run a successful system.

      1) Design product to meet needs of your audience
      2) Design the implementation that you think will handle the load the best (with lots of load testing and simulations to make sure it meets expected demand)
      3) Build product
      4) Watch it behave in the wild... Realize that actual demand is considerably higher than expected demand and will continue to grow
      5) Performance slows with more users... you need a solution that will the push the date of catastrophic overload

    • Re: (Score:3, Insightful)

      by CptPicard ( 680154 )

      The key architectural performance issues in large web apps like Facebook are about scalability by clustering and parallelism and caching... usage of proper higher-level languages helps in this (think how pure-functional programming removes shared state and Google's mapreduce for example), while using a lower-level language may give a speedup on single individual machines but makes the architectural problems harder to tackle.

  • by crossmr ( 957846 ) on Sunday January 31, 2010 @10: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.

    • by stimpleton ( 732392 ) on Sunday January 31, 2010 @12: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"
  • Resin Quercus (Score:4, Interesting)

    by parryFromIndia ( 687708 ) on Sunday January 31, 2010 @10: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.
    • Re: (Score:3, Informative)

      Here is the URL in case people are interested in checking this out - http://www.caucho.com/resin-4.0/doc/quercus.xtp [caucho.com] .
      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
    • by julesh ( 229690 )

      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.

      The main problem is lack of support for some of the quite popular extensions that are widely used in PHP apps. Just looking over the list of what's supported and what isn't, I find qui

  • Akamai sucks (Score:3, Interesting)

    by Turmoyl ( 958221 ) on Sunday January 31, 2010 @10: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.

Avoid strange women and temporary variables.

Working...