Announcement

Collapse
No announcement yet.

Quick Test: PHP 5.6 Against Facebook's HHVM

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Quick Test: PHP 5.6 Against Facebook's HHVM

    Phoronix: Quick Test: PHP 5.6 Against Facebook's HHVM

    While PHP 5.6 was just released, Facebook's HHVM remains a competitive, alternative implementation that continues gaining new features and is being ruthlessly optimized by Facebook engineers...

    http://www.phoronix.com/vr.php?view=MTc3NTY

  • #2
    That is because HHVM crate a progressive refined cache, you should try to run it "some times" to have good result.

    http://hhvm.com/blog/1817/fastercgi-with-hhvm look out the WordPress section

    Comment


    • #3
      Where the hell is everyone?

      Comment


      • #4
        Originally posted by RoyBellingan View Post
        That is because HHVM crate a progressive refined cache, you should try to run it "some times" to have good result.

        http://hhvm.com/blog/1817/fastercgi-with-hhvm look out the WordPress section
        phoronix-test-suite is a CLI utility, not using the server component.
        Michael Larabel
        http://www.michaellarabel.com/

        Comment


        • #5
          HHVM first run will always be slower than standard PHP. In real world usage I've seen HHVM trump PHP in such way that other sysadmins were totally abashed of their system performance. I myself did migrate a Magento CE ecommerce from a big 8 core 20gig of RAM machine to a smaller VPS with 2 core and 4gig of RAM using Nginx + HHVM, going from a slow, 6s+ peak load time to less than 2s peak load time.

          I really hope that PHP-ng performance will see a huge increase. You know sometime you simply can't use a cache in front of your application.

          Comment


          • #6
            Other implications?

            What about Quercus?

            Comment


            • #7
              Originally posted by mateli View Post
              What about Quercus?
              Nice find, I didn't knew about this project. I do wonder about memory usage though. Almost every time I've deployed Java web application they were memory hogs.

              Comment


              • #8
                PEAK MEMORY USAGE: 556.339 MB
                PEAK MEMORY USAGE (emalloc): 78 MB
                What an absolute pig, and still less impressive.

                Comment


                • #9
                  Originally posted by werfu View Post
                  HHVM first run will always be slower than standard PHP. In real world usage I've seen HHVM trump PHP in such way that other sysadmins were totally abashed of their system performance. I myself did migrate a Magento CE ecommerce from a big 8 core 20gig of RAM machine to a smaller VPS with 2 core and 4gig of RAM using Nginx + HHVM, going from a slow, 6s+ peak load time to less than 2s peak load time.

                  I really hope that PHP-ng performance will see a huge increase. You know sometime you simply can't use a cache in front of your application.
                  Why does this sound like HHVM is just using a more aggressive pre-cache system, by chewing up memory to do so?

                  Comment


                  • #10
                    Originally posted by Marc Driftmeyer View Post
                    Why does this sound like HHVM is just using a more aggressive pre-cache system, by chewing up memory to do so?
                    From personal experience, HHVM in fact use LESS memory than PHP once its warmed up. In my Magento example the previous system was using 18Gig at load while the HHVM setup I did was rarely going past 1GB. I did go from Centos 6.2 to Ubuntu 12.04, the former being an Apache+mod_php and MySQL setup to a new Nginx+HHVM and Percona setup. Magento is a pig when no caching is involved. Most people will deploy Varnish in front of it, but in this case there was too many dynamic features to use it.

                    Correct me if I'm wrong, but if I remember well HHVM compiles php files and store the result as the PHP VM will generate PHP bytecode and the OpCache extension will store functions in the process memory.

                    Comment

                    Working...
                    X