HHVM is the greatest thing since sliced bread

Legoktm is a platform engineer for the Wikimedia Foundation. He wrote this in his volunteer capacity with members of the MediaWiki Core team.

No seriously, it is.

HHVM stands for "HipHop Virtual Machine". It is an alternative PHP runtime, developed by Facebook and other open source contributors to improve the performance of PHP code. It stemmed from HipHop for PHP, an earlier project at Facebook which compiled PHP into C++ code. Compared to the default PHP runtime, it offers significant speedup for many operations.

In March 2014, a group of MediaWiki developers started working on ensuring that the codebase, along with the various PHP extensions used on Wikimedia servers, were compatible with HHVM. This involved making changes to MediaWiki, filing bugs with the HHVM project, and often also submitting patches for those bugs.

Users will see performance improvements in many places, especially when editing extremely large articles. If you're interested in helping the development team out with finding bugs, or just want your editing experience to be faster, you can enable the "HHVM" betafeature in your preferences.

We caught up with longtime MediaWiki developer and lead platform architect Tim Starling and asked him a few questions about the HHVM migration:

What is HHVM?

HHVM is a new implementation of the PHP language, written in C++. It has a rewritten runtime — that is to say, most of the functions exposed to PHP code have new implementations. It has a JIT compiler which can translate small snippets of PHP code to machine code.

What have the performance gains of HHVM been so far? Are they expected to increase over time?

At the moment, it is faster by roughly a factor of two. This is somewhat disappointing since the old HipHop compiler gave us a speedup of 3–5 depending on workload, although at the cost of an hour-long compile time. The performance gain is expected to increase over time, due to:

• Deployment of RepoAuthoritative^[1] mode. This involves analysing the PHP code for a few minutes prior to deployment, in order to generate more efficient HHVM bytecode. It is said to give a speedup of about 30%.
• Optimisation of HHVM for MediaWiki's workload. Brett Simmers of Facebook has offered to spend some time on this after we have fully deployed HHVM.
• Profiling and optimisation of MediaWiki running under HHVM. We expect big gains here, since not much profiling work has been done on MediaWiki while Ori and I have been working on HHVM. Even the Zend performance of MediaWiki is sub-optimal at present.
• Ongoing performance work on HHVM by Facebook. Facebook have a performance team which constantly improves the performance of HHVM.

What sort of impact can users expect from the deployment of HHVM? What sort of issues might users run into?

We expect to see crashes and other fatal errors, and also more subtle bugs such as incorrect HTML generated by Lua or wikitext. Note that as we are rolling out HHVM, we are also upgrading from Ubuntu 12.04 to Ubuntu 14.04, which means different versions of many system libraries and utilities. When we move the image scalers to Ubuntu 14.04, there may be changes to SVG rendering.

What effort has gone into ensuring that HHVM performs well and is reliable, especially at Wikipedia's scale?

We have tested HHVM's performance by benchmarking, and also under real load by diverting a proportion of Wikipedia's traffic to a single HHVM backend server. We have some assurance from the fact that Facebook has been running HHVM for years in production, and their scale is significantly larger than our scale. Facebook's experience also gives us some confidence as to reliability.

With any open source project, it is difficult to give assurances as to reliability. PHP has not been uniformly reliable for us, and has presented all sorts of challenges for us over the years as we have scaled up. HHVM's architecture is built with much more awareness of the challenges of scaling than PHP was. So we have reason to think that HHVM will prove to be a more stable platform for a busy website in the long term.

What was the biggest challenge to rolling out HHVM?

Integration of Lua. I don't think anyone has integrated another language with HHVM before, in the same address space. We did it by rewriting HHVM's Zend compatibility layer, allowing our existing Lua extension for Zend to be also compiled against HHVM, with only a few instances of cheating (#ifdef).

What is Hack and do you think it will affect Wikimedia development?

Hack is the new name for the language extensions that Facebook has progressively added to the syntax of PHP over the last four years in HipHop Compiler and HHVM. It also refers to the static type checker that they have recently introduced. Hack allows types to be specified for function return values, and extends the existing support for specified types in function parameters. The net effect is to allow an existing PHP codebase to be progressively migrated to strong typing, with many type checks being done pre-commit instead of at runtime. This is beneficial for developers of large applications, and helps to avoid errors being seen by users at runtime.

For now, we are committed to compatibility with PHP, and so it is difficult for us to make use of Hack's language extensions, except in WMF-specific services and tools. I would love to see a move towards language harmonization by PHP towards Hack – for example, return type hints could easily be added. I'm not sure of the reason for the split, since PHP does not strike me as an especially conservative community.

Currently logged-out users have a significantly faster experience than logged-in users. Is it realistic to expect that logged-in users will one day have the same experience as logged-out users? If so, when?

HHVM by itself will not provide performance parity for most users. It will help to reduce parser cache hit times, and for many articles, for users near our main US data centre, the difference between logged-in and logged-out page view times may be imperceptible. But for users outside the US, we will continue to serve logged-out page views from the nearest cache, whereas logged-in page view requests are forwarded to Virginia, which will add 100-300ms due to the speed of light delay. This is not easy to fix.

Parser cache misses could be reduced or eliminated, but page save times are somewhat more difficult, in my opinion, especially if we continue to support pre-edit spam and vandalism detection. Some amount of processing is needed to detect vandalism – is it appropriate to pretend that we have saved the page when such processing is still going on, and to send a message later if the edit is rejected? And if we do that, do we show the updated site to the user while processing is in progress?

After HHVM is fully deployed, what are the next big projects to improve performance?

We are planning to work on editor performance, especially VisualEditor. Also, as previously noted, there will be ongoing profiling and optimisation work which will cumulatively improve performance.

More information is available at mw:HHVM/About, and information about the current development process can be found at mw:HHVM.

P.S.: If you too find HHVM to be awesome, you can leave your thanks to the developers here.

Next "Technology report" →

In this issue

8 October 2014 (all comments)

In the media

Featured content

Traffic report

Technology report

+ Add a comment

Discuss this story

These comments are automatically transcluded from this article's talk page. To follow comments, add the page to your watchlist. If your comment has not appeared here, you can try purging the cache.

UX approach feedback

Thanks for the write-up. Sounds promising. You asked:

... is it appropriate to pretend that we have saved the page when such [spam and vandalism detection] processing is still going on, and to send a message later if the edit is rejected? And if we do that, do we show the updated site to the user while processing is in progress?

I would say yes to both questions, on the principle that the needs of the many outweigh the needs of the few.

Many good editors make rapid-fire, serial micro-edits, with discrete edit summaries; many more editors often take several edits to fix a citation to their satisfaction: both large sets of users would certainly benefit from quick feedback, just as Wikipedia benefits from their test-driven edits.

Screw the UX of the fewer (I hope) suspected spammers or vandals. They can wait. -- Paulscrawl (talk) 01:43, 11 October 2014 (UTC)[reply]

I'd be very annoyed to learn that a failed vandalism check caused me to lose an hour's worth of editing work—especially if I logged out and/or killed the session after "confirming" the change. At the very least, automatically-rejected article edits should be saved, even if they're not committed. (Although that may open up the possibility of DoS attacks in which a malicious party repeatedly creates single-use accounts and makes one large spam edit from each account, causing the saved edit files to eat up space. I don't see any simple solution to that.) —Twice Nothing (talk) 20:20, 11 October 2014 (UTC)[reply]

Specialist-targeted details

Nice effort to engage with non-specialists at the top, but could you explain for us, for example: "The net effect is to allow an existing PHP codebase to be progressively migrated to strong typing, with many type checks being done pre-commit instead of at runtime.”? Perhaps a wider editorship should know about these things. Tony (talk) 08:09, 11 October 2014 (UTC)[reply]

Why? It's strictly a back-end detail. No editors (qua editors) need ever be concerned with it. —Twice Nothing (talk) 20:20, 11 October 2014 (UTC)[reply]

Just because editors need not be concerned in order to edit, doesn't mean there's anything wrong with being curious. Personally I think the more the editors know about the technical details (So long as they have the option of not knowing if they get bored), the better. As for the the original question, I'll try my hand at clarifying: Computer programs are generally made up of data, and code or functions that manipulate that data. The data has various "types". For example, it could be a number, a string (computer speak for a series of letters), a boolean (true or false), an array (computer speak for list), or a number of custom made types (classes). PHP generally doesn't care about the types that much. If you have a function named add2, which adds two to a number, PHP will let you output data of any type from that function. This allows for a certain amount of flexibility at the expense of not automatically being able to catch certain types of silly errors (like adding 2 to the string "dog"). If you need to insist that the function only works on numbers, you can add a check, but it is checked when the user is actually running the program (At run-time). With the static typing mentioned above, you can mark certain functions as only outputting data of certain types. If enough things are marked like that, the computer can automatically check that people are not making certain mistakes. Thus such errors can be caught before the code is put on wikipedia servers (pre-commit) instead of when you're editing a page (at runtime). Hopefully that made sense. Bawolff (talk) 22:28, 11 October 2014 (UTC)[reply]