Stories
Slash Boxes
Comments

SoylentNews is people

posted by n1 on Wednesday December 31 2014, @08:37AM   Printer-friendly [Skip to comment(s)]
from the drum-machine-vst dept.

It’s been shown that even small delays in response time on websites can result in sharp declines in user retention. Now Ori Livneh writes on the Wikimedia Blog that over the last six months the Wikimedia Foundation has deployed a new technology that speeds up MediaWiki, Wikipedia’s underlying PHP-based code using a just-in-time compiler. HipHop Virtual Machine (HHVM) , an open-source virtual machine designed for executing programs written in Hack and PHP, reduces the median page-saving time for editors from about 7.5 seconds to 2.5 seconds, and the mean page-saving time from about 6 to 3 seconds which with than 100 million edits in 2014, means saving a decade’s worth of latency every year.

PHP is a dynamic, interpreted language, so it has the inherent performance disadvantage all interpreter languages have when compared to compiled languages such as C. HHVM is able to extract high performance from PHP code by acting as a just-in-time (JIT) compiler, optimizing the compiled code while the program is already running. The basic assumption guiding HHVM’s JIT is that while PHP is a dynamically typed language, the types flowing through PHP programs aren’t very dynamic in practice. HHVM observes the types present at runtime and generates machine code optimized to operate on these types. HHVM still fulfills the role of a PHP runtime interpreter, serving requests immediately upon starting up, without pre-compiling code. But while running, HHVM analyzes the code in order to find opportunities for optimization. The first few times a piece of code is executed, HHVM doesn’t optimize at all; it executes it in the most naive way possible. But as it’s doing that, it keeps a count of the number of times it has been asked to execute various bits of code, and gradually it builds up a profile of the “hot” (frequently invoked and expensive to execute) code paths in a program. This way, it can be strategic about which code paths to study and optimize.

According to Livneh, in addition to the improved response time the CPU load on MediaWiki's app servers has dropped drastically, from about 50% to 10%. MediaWiki IT "has been able to slash their planned purchases for new MediaWiki application servers substantially, compared to what would have been necessary without HHVM."

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Interesting) by Anonymous Coward on Wednesday December 31 2014, @08:59AM

    by Anonymous Coward on Wednesday December 31 2014, @08:59AM (#130470)

    Facebook did something useful for once. (They make HHVM)

    If CPU time is a limiting factor, maybe we should port media wiki to a better language. Having something as important as wikipedia hosted on an overly complex JIT run-time in a famously unsafe language seems like a bad choice.

    • (Score: 3, Funny) by Geotti on Wednesday December 31 2014, @09:29AM

      by Geotti (1146) on Wednesday December 31 2014, @09:29AM (#130475) Journal

      port media wiki to a better language

      What would you suggest? Perl? Let's ask The Mighty Buzzard if he thinks that's funny.

      It works. Leave it alone. (If you really do insist on porting it, however, Erlang would probably be one of the better choices.)

      • (Score: 2) by TheRaven on Wednesday December 31 2014, @09:55AM

        by TheRaven (270) on Wednesday December 31 2014, @09:55AM (#130479) Journal
        I'm a bit surprised that the dynamic content on Wikipedia is a dominant factor for them. The ratio of people editing to people viewing the code must be pretty low, and for people reading the static content you should be serving without needing to run any PHP.

        Oh, and Soylent editors: the quote that's a big part of TFS doesn't tell us anything about HHVM - every dynamic language implementation with reasonable performance since Self (i.e. last 20-25 years, including modern JavaScript implementations) has used type feedback and type specialisation techniques.

        --
        sudo mod me up
        • (Score: 2) by TheRaven on Wednesday December 31 2014, @10:40AM

          by TheRaven (270) on Wednesday December 31 2014, @10:40AM (#130484) Journal
          After reading TFA, I discover that the word 'editing' somehow lost itself in the translation to Soylent. HHVM improves the speed for people editing, which is probably nice.
          --
          sudo mod me up
          • (Score: 3, Informative) by Ryuugami on Wednesday December 31 2014, @01:11PM

            by Ryuugami (2925) on Wednesday December 31 2014, @01:11PM (#130505)

            After reading TFA, I discover that the word 'editing' somehow lost itself in the translation to Soylent. HHVM improves the speed for people editing, which is probably nice.

            The final sentence of the first paragraph of TFS (emphasis mine):

            HipHop Virtual Machine (HHVM) , an open-source virtual machine designed for executing programs written in Hack and PHP, reduces the median page-saving time for editors from about 7.5 seconds to 2.5 seconds, and the mean page-saving time from about 6 to 3 seconds which with than 100 million edits in 2014, means saving a decade’s worth of latency every year.

            It's not lost, it just took a different route :)

            --
            If a shit storm's on the horizon, it's good to know far enough ahead you can at least bring along an umbrella. - D.Weber
      • (Score: 0) by Anonymous Coward on Wednesday December 31 2014, @09:11PM

        by Anonymous Coward on Wednesday December 31 2014, @09:11PM (#130627)

        Their old PHP supported C extensions (they already had 3) for performance critical stuff. They have upstreamed some work to get them working with HHVM, and could port more stuff to that. It might make sense to extend that interface to support safer languages, Go might be a good choice. HHVM has native support for Hack, so thats an obvious option (which they are apparently watching). I wouldn't choose Erlang if I was trying to improve performance: its an amazing choice for fault tolerance and incremental update, but their front end is already sharded so I don't see the point of using erlang there.

        HHVM has much better profiling tools, so deciding what parts to port should be much easier now.

      • (Score: 0) by Anonymous Coward on Wednesday December 31 2014, @09:49PM

        by Anonymous Coward on Wednesday December 31 2014, @09:49PM (#130629)

        Perl would be a good choice.

        Perl is faster than PHP:

        http://blog.famzah.net/2010/07/01/cpp-vs-python-vs-perl-vs-php-performance-benchmark/ [famzah.net]

        But, of course, if one is a helpless prisoner of fashion then one is doomed to use PHP.

  • (Score: 3, Insightful) by davester666 on Wednesday December 31 2014, @09:22AM

    by davester666 (155) on Wednesday December 31 2014, @09:22AM (#130472)

    they still keep humping that fundraising drive like they are just about to have to close the doors....

  • (Score: 2) by Geotti on Wednesday December 31 2014, @09:24AM

    by Geotti (1146) on Wednesday December 31 2014, @09:24AM (#130473) Journal

    MediaWiki IT "has been able to slash their planned purchases for new MediaWiki application servers substantially

    I guess it'd be too much to ask to slash their requests for donations as well, eh?

    • (Score: 2) by c0lo on Wednesday December 31 2014, @01:59PM

      by c0lo (156) Subscriber Badge on Wednesday December 31 2014, @01:59PM (#130518) Journal

      MediaWiki IT "has been able to slash their planned purchases for new MediaWiki application servers substantially

      I guess it'd be too much to ask to slash their requests for donations as well, eh?

      But... surely you realize with extra funds they can support 20 times more edits in the same time?

      (large grin)

      --
      https://www.youtube.com/watch?v=aoFiw2jMy-0
    • (Score: 3, Insightful) by paulej72 on Wednesday December 31 2014, @04:38PM

      by paulej72 (58) on Wednesday December 31 2014, @04:38PM (#130557) Journal
      If they got rid of the requests then their servers would be twice as fast again.
      --
      Team Leader for SN Development
  • (Score: 2) by CRCulver on Wednesday December 31 2014, @01:32PM

    by CRCulver (4390) on Wednesday December 31 2014, @01:32PM (#130514) Homepage

    It’s been shown that even small delays in response time on websites can result in sharp declines in user retention.

    I don't doubt that this development will prove useful for certain websites, but surely Wikipedia was only a testbed for this and no one is suggesting it really needed the development. Wikipedia has progressively become the internet's one-stop shop to find out any information imaginable, and the idea that users would get frustrated by load times and go somewhere else is laughable.

    • (Score: 2) by c0lo on Wednesday December 31 2014, @02:02PM

      by c0lo (156) Subscriber Badge on Wednesday December 31 2014, @02:02PM (#130519) Journal

      and the idea that users would get frustrated by load times and go somewhere else is laughable.

      Laughable you say? (shudders) ...what if they go to Facebook?

      --
      https://www.youtube.com/watch?v=aoFiw2jMy-0
      • (Score: 0) by Anonymous Coward on Thursday January 01 2015, @11:18AM

        by Anonymous Coward on Thursday January 01 2015, @11:18AM (#130750)

        what if they go to Facebook?

        fortunately Facebook uses HHVM too

    • (Score: 2) by datapharmer on Wednesday December 31 2014, @06:11PM

      by datapharmer (2702) Subscriber Badge on Wednesday December 31 2014, @06:11PM (#130579)

      Or they could have just enabled zend opcache and saved a llot of development time and complexity...