WP Engine Sponsors John James Jacoby to Work on HHVM Compatibility with BuddyPress

wp-engine

WP Engine announced today that the company will be sponsoring John James Jacoby to work on HHVM compatibility for BuddyPress. Mercury, the host’s new enterprise HHVM WordPress hosting platform, debuted last month with initial benchmarks indicating performance improvements of up to 600%.

Jacoby is the project lead for BuddyPress and a former employee of 10up, the agency WP Engine partnered with to build Mercury. He also recently created an HHVM configuration for Varying Vagrant Vagrants, which makes it easy to test WordPress on HHVM in a local development environment.

Taking a Chance on BuddyPress

WP Engine is sponsoring the HHVM + BuddyPress compatibility work as part of its Labs project, headed up by Tomas Puig. Labs is a separate team within the company that works on new technologies and open source contribution. “Right now we can’t even load test BuddyPress without it breaking,” Puig said.

Why is WP Engine prioritizing BuddyPress compatibility with HHVM? The company is taking a chance on WordPress’ premier social networking plugin and, if successful, will become the fastest hosting platform available for running BuddyPress.

“We saw such a surge of interest when we announced Mercury. We don’t have a lot of BuddyPress customers,” Puig told the Tavern. “But I think if we get BuddyPress performing well for HHVM, then people will want to use it even more. Also, core and bbPress work great with HHVM so we felt the third project should too, so everyone can benefit.” The technical objectives of the compatibility effort are to get BuddyPress working at parity with how it currently runs on PHP-FPM.

“In my mind i’d love to see the major WP projects work with it,” Puig said. “If we see a 3-8x improvement in speed, it’s going help everyone trying to deploy BuddyPress. Also, I think more people will use it if it’s easier to support high user loads.”

Puig did not have immediate access to the number of WP Engine customers currently running BuddyPress, but he said the company will continue with the investment regardless of small usage numbers. “Technology, once it’s a performant, great option, will get adopted,” he said. “But once the main body of work and the tests are built it gets much easier to keep that way moving forward.”

WP Engine is engaging the Facebook team on the effort as well, as there might be things in HHVM that are preventing it from being compatible with BuddyPress. The company contracted Jacoby to work on the project for the month of December, before he gets started on the new year with his BuddyPress, bbPress, and GlotPress development. “It’s a bit unknown how much code needs to change to make it HHVM compliant, so we wanted the person who is the most familiar with the code base,” Puig said.

WP Engine sponsoring Jacoby to work on this initiative benefits the open source BuddyPress plugin in a couple of major ways. In addition to supporting the project lead in working with the software, the HHVM compatibility project also ensures the future of BuddyPress working with modern technologies. Many believe that HHVM is going to revolutionize PHP, which means that hosting companies will soon be rushing to adopt it. Investing in BuddyPress compatibility with HHVM now means that the plugin won’t be left in the dust.

Would you like to write for WP Tavern? We are always accepting guest posts from the community and are looking for new contributors. Get in touch with us and let's discuss your ideas.

13 Comments


  1. “we can’t even load test BuddyPress without it breaking”

    That’s strange – I have a testing VM with HHVM running WordPress + BuddyPress + BuddyPress Docs perfectly.

    Report


    1. I’ve been working with Tomas and John Jacoby on this – we also have HHVM running with BuddyPress and it works fine for a very small amount of concurrent users. If we put any kind of load on it, HHVM crashes. It is very strange. We have some custom tuning of HHVM that was put in place after working with the Facebook engineers that makes WordPress core blazing fast, but it could be incompatible with BuddyPress – this is the kind of thing we’re working to figure out.

      Report


      1. We used Siege and Blitz.io. Sieges at 150 concurrent users with the -i flag and a text file full of BP end-point URLs would never complete — Siege would give up, as HHVM had segfaulted spectacularly.

        Blitzes scaling from 1-300 users over a few minutes time would cause it to top out at maybe 175 concurrent users or so and the *BAM* segfault again.

        There’s no coming back from that, unfortunately — you have to restart HHVM. PHP-FPM, when under load, will at least come back to some level of functionality as older transactions time out.

        Report


      2. Riiiight about where we fell over, too:

        Transactions: 914 hits
        Availability: 43.79 %
        Elapsed time: 280.50 secs
        Data transferred: 4.41 MB
        Response time: 3.71 secs
        Transaction rate: 3.26 trans/sec
        Throughput: 0.02 MB/sec
        Concurrency: 12.09
        Successful transactions: 974
        Failed transactions: 1173
        Longest transaction: 29.73
        Shortest transaction: 0.12

        Report


      3. sorry but can you decipher that? at what number concurrent users did HHVM crash?

        Report


      4. It was actually the number of hits, not the number of users. Siege started at 150 concurrent users and maintained that level throughout the run.

        Report


      5. does the amt of resource like RAM or CPU make a difference in this or is it something technical with HHVM?

        Report


      6. As far as we could ascertain, it’s endemic to BuddyPress and/or HHVM (why not both?). We saw this behavior on small Vagrant boxes and we saw it on 8 CPU 8GB RAM beefy boxes in colocated datacenters.

        Report


  2. Really cool to see WP Engine sponsoring Jacoby to work on this full-time which will not only benefit them, but the project as a whole. It would be cool if somehow, more companies sponsored development this way though I wouldn’t want to see companies with big pocket books override the needs and wants of the common user.

    Report


    1. Totally agree Jeff. I think company sponsorship and community driven crowd funding are clear winners. There are many companies but right off the bat Envato comes to mind as an obvious choice.

      Report

Comments are closed.