HHVM is not for WordPress

So, I stopped using HHVM and fell back to ye-olde php5-fpm because HHVM got too good at what it is doing.

HHVM itself is beautiful and I like it for the administration simplicity and throughput benefits it offers. The JIT is performing better and better by each new release. This is absolutely brilliant if you’re writing new, clean, strictly typed and simple PHP code. Some of the engineering tradeoffs to make this work, mostly the translation cache size limits, will mean badly written, as in traditional, PHP code will eventually fill up the cache and HHVM will exit with an assertion.

So far sounds good and sensible, so what’s the issue? Even WordPress is getting cleaner and better written by the release and performing better and better on HHVM. Plugins are not.

Running WordPress without also having to run arbitrary plugins is not a realistic deployment scenario. Especially since the sources of the worst kinds of typing polymorphism for the HHVM JIT seem to be the caching plugins and in general anything which inserts itself deep and early into the request response context like any application firewall plugins.

In my experience, out of the box on a normal WordPress installation, it will currently assert 3..5 times per day on a newer HHVM. The older versions at first did not assert at all, then they started to go at a rate of a few times a week and now we’re already up to a few times a day.

How about just raising the limits? I tried setting the limits up to the next power of two every time I had an assertion. This carries a startup time penalty and makes HHVM, quite understandably, use more memory at runtime. I also found out, that at very high levels, after an assert, HHVM will not start again until you nuke out the hhvm.hhbc SQLite repository. I quite agree with the documentation on the “extremely cryptic errors” part.

What about the ugly way around, simply just kicking the process back up all the time? That can work for you. During the startup periods clients will receive 502s. This is a service level design consideration.

I’ve rather opted to go back to a more traditional way. PHP 7 will land soon enough and bring with it comparable performance gains.

Leave a Reply

Your email address will not be published. Required fields are marked *