Experimenting with HHVM at Etsy
codeascraft.comThe new stuff happening in the PHP space is really really awesome.
HHVM + HACK + XHP is an entirely different experience compared to writing PHP. Code can actually be very clean and lots of bugs can be found that may have previously gone unnoticed + performance benefits.
Just wanted to say FB is doing an exceptional job with these projects.
Calling setlocale because the user you're currently processing has a different locale? What the..?
Notice: what works in UNIX utilities is not what works for web apps serving many users simultaneously. In fact, I'm pretty sure this doesn't work for UNIX utilities either and is just something you should never touch with your libc. It's like calling non-reentrant strtok, some of this stuff just doesn't exactly fit into todays world.
The PHP library is (surprise!) sort of a mess when it comes to things that use the libc locale (which tend to offer no other way of switching locale or encoding), things that use the locale settings from the intl extension, things that respect the default_charset setting (and/or the input_encoding setting, output_encoding setting, or internal_encoding setting), and things that actually take one or more of these settings as arguments.
It ends up changing the output of icu-based libraries, localizing stuff like number formatting. Otherwise you're re-implementing that in userland code, which is likely to be much slower.
The good news about hhvm is that with the newest builds from the past few months you can finally run it longer than a week without memory leaks and crashing under high loads.
If you look at the changelog, you can see it really is a beta product that people use in production anyway
https://raw.githubusercontent.com/facebook/hhvm/master/NEWS
"Ditko" 26-Feb-2015 finally solved me having to restart it every several days
I'm very eager to compare PHP7 in production
This is what caused me to abandon HHVM for plain ol' PHP around a year ago. I was running it in Docker containers and the memory leaks would regularly crash my containers if left unattended for more than a couple of days.
It was quite frustrating because I noticed some definite performance gains (e.g., ~2x faster page loads, etc.), but ultimately opted for PHP's stability.
The benefit to running all this in Docker is that I can swap HHVM back in relatively easily (unless it's changed really dramatically over the past 10 months or so). Your comment has me tempted to give it another shot!
Update: we had an hhvm install today that crashed after 15 days or so.
Apparently this still happens but instead of several times per month, it is now a couple times per month.
Sigh, well PHP7 is right around the corner.
Shameless self promotion: I wrote hussar[0], a tool that uses HHVM for PHP static analysis in projects that can't run HHVM directly. Etsy says "getting [their] code to run on HHVM was relatively easy", but my experience has been the opposite. Previous discussion on HN here: https://news.ycombinator.com/item?id=9071854
This is a great write up. I have been skeptical of converting to HHVM for a while because of a bad experience I had several years ago. I've been following the HHVM project off and on for a while now, but it really sounds like it may be ready for some smaller projects who don't have the resources of an Etsy to try it out.
And later this year, PHP 7 is coming, which should bring huge performance improvements.
Beyond HHVM, in fact, has oob compiler. We've opted to hold off until 7 is out - HHVM extension support is still patchy.
Plus the whole "warm-up" procedure just seems immensely patchy to me - hopefully no such thing will be needed in PHP7.
bespoke endpoints sound like a good compromise, but I wonder why they stick with php for the general apis that the bespoke endpoints consume? Wouldn't they get better scalability if they moved that backend logic to something like Play, which would give you NIO on a jvm?
EDIT: Removed mention of "shared-nothing", which I misunderstood.
Isn't shared nothing a scalable architecture?
Ok, I hadn't seen that phrase to describe that kind of architecture before, thanks. Still though, it seemed they were describing each node's "build-the-world" process as onerous. Is HHVM thread-per-request?
Yes. It's why they had problems with certain non-thread safe routines like locale.
Anything that touches our production databases, mostly sharded mysql, needs to go through our php orm.
We do have other contained infrastructure that is written in some other languages like go and scala.
I was also curious about this. If the main traffic interface is bespoke, I'm sure Esty would investigate other solutions. It would make the most sense to also experiment with Bespoke since it's just an interface that talks to other APIs, likely without any business logic and a huge codebase. It orchestrates other APIs into 'views' for the consumer so you have one consolidated endpoint.
I'd personally be curious if they experimented with Go lang for this. Low memory, fast startup, fast at run. It makes more sense to use another language for bespoke than anywhere else in their stack, at least from my limited external viewpoint that is :)
It does mean that every tool they've written to work with their stack now needs to have a Go equivalent. For some things, that'll be easy. It also means they now need people who know Go, which means any of their engineers can't just work on the code without learning.
It also means deployment will be different.
While the technology might make more sense, there's often enough reasons to not use it if you've specialized into a certain ecosystem.
Ported 200k+ line app to Go over a year ago. Happiest day of my life removing any traces of PHP from my systems.
I guess the question I've been having is that if I want to begin a new project with performance as a main priority, should I use HHVM+PHP or HHVM+Hack over something like Java or Go, or is it more for making existing PHP codebases more performant.
I'm a little surprised that HHVM would make or break anyone's decision to use PHP, since I'd think that there are more important language design concerns and features that ought to figure before it came down to that... at least in a PHP-vs-Java sort of fight, anyway. Big questions like your preferred form of typing (strong/weak, dynamic/static/Hindley-Miller inference, etc), threading, ease of writing list comprehensions, whether you need to have functions as first-class objects, et cetera et cetera. Or the ability to hire developers who use that language.
For me I guess it's choosing the right weapon for the right enemy. If my greatest priority is shipping something tomorrow, I'll choose PHP or Python because I can code that in a blink.
However, if I'm able to hang back and take some time to develop something, priorities like being able to handle X I/O writes or, as you point out, threading becomes more relevant.
Depends on what you're building, honestly.
I think that it's easy enough to get a site running entirely on PHP--well tested, well supported, architecturally sound, and rewrite services into <noninterpreted-language-of-choice> as you hit performance bottlenecks.
If performance is absolutely critical to your app, then you may consider writing everything in Java/Go/C++, but it's pretty brutal for doing templating and whatnot. Besides, once you generate the page, there's a good chance you're going to cache a good part of it anyhow!
IMHO: HHVM/Hacklang are cool and i appreciate Facebooks contributions to building a better PHP enviroment... but at the end of the day, it feels like someone trying to put a V12 engine in a golf cart. It's cool if you are already driving a golf cart, otherwise it's weird.
So if you have the chance to start fresh: choose Java or Go. Or anything else... (define "performance"?)
The development cycle with PHP/Hack is fast. You code, then press F5 in the browser and see result instantaneous. With other languages, a static compilation time of even just a few seconds is very contra productive and annoying. Writing less (redundant) code helps a lot with prototyping too (dynamic typing, optional static types). The documentation on php.net with comments on each page (from the community) is very good.
Node/IO.js and Go have their advantages, especially if one wants to use WebSocket.
Nowadays, half of the code is client side anyway (be it HTML5 JS (maybe with React/Angular) or mobile apps) - in such cases the server output and receives a lot of JSON. And then Node.js/Go/HHVM are about equal as good in benchmarks, at least in my personal benchmarks (10.000 -100.000 requests/s with Apache AB tool).
Go or Java is still faster than HHVM/PHP7. I'm writing my new project (Magento Go (wordplay) ;-) ) in GoLang.
I work with Magento a lot lately. Very interested in hearing about this!
This is great. After being one of the early contributors to documentation and clearing up the (admittedly ridiculous) on-ramping guides for what was then HipHopPHP, I'm really happy to see it get more traction. I deploy it in production for a webapp that is more or less simple CRUD on the outside but does some relatively expensive scheduled batch processing of number crunching. The differences are huge and allow me to keep it to a single - albeit big - dedicated machine.
It's come a long way and I'm excited to see further improvements.
Is a comprehensive test suite for PHP a byproduct if this?
Last time I checked PHPs own tests only had about 30% coverage, and with a famously idiosyncratic language like PHP, which apparently needs a massive internal overhaul to increase speed, that seems less than optimal.
I thought the test suite was one of the best things to come our of multiple ruby implementations, though I read recently that core Ruby ignore it and so regularly introduce bugs that it would catch.
There's a talk Dan gave on this same topic at PHP UK 2015 that's worth watching.
Be aware that while HHVM is more or less compatible with PHP now, there is no guarantee it will be in the future,and Hack is definitely not backward compatible with PHP. Not even talking about PHP C extensions.
I would love to move onto HHVM and since mostly run own PHP code 3rd party code compatibility is not a problem, BUT unfortunately the editor I use (PHP Storm) doesn't yet support HHVM :(
what editors do people that are using HHVM use?
HHVM is just a PHP JIT compiler. It's not a different language.
That is Hack.
I wasn't clear enough I now realize in my post, I meant supporting Hack language that comes with HHVM (type annotations etc) in PHP Storm
But those are two things. You can move to HHVM and not use Hack.
PHPStorm supports xdebug and HHVM: https://youtrack.jetbrains.com/issue/WI-18817#comment=27-865...