4 ms·

Box's HHVM Migration

82 points by tomkwok 11y ago

VeejayRampay 11y ago
I wish Twitter had pulled a HHVM with Ruby on Rails. I really do cause HHVM's benefits for PHP-based code bases looks appealing.
- ciupicri 11y ago
  Hasn't Twitter switched to Scala?
  - draven 11y ago
    They certainly seem to have a lot of infrastructure running on the JVM (both Scala and Java.) There is some information there (with emphasis on Scala, obviously): http://www.typesafe.com/resources/case-studies-and-stories/new-tweets-per-second-record-and-how http://www.typesafe.com/resources/case-studies-and-stories/n...
  - VeejayRampay 11y ago
    They have for at least parts of their infrastructure but there was a time where they were heavily invested in Ruby on Rails just like Facebook and PHP. They could have chosen to work on the framework and Ruby itself to make things better, they chose to move on to greener pastures instead. As a Ruby developer I regret that didn't "pull a HHVM", would have made my life easier, just HHVM and the whole FB/HHVM/Hack ecosystem is making PHP devs' life easier.
    - chrisseaton 11y ago
      Are you just after a faster Ruby? We're working on an implementation of Ruby that is often an order of magnitude faster than anything else out there http://www.chrisseaton.com/rubytruffle/ http://www.chrisseaton.com/rubytruffle/. Or is it the typing and other infrastructure you wanted?
      - VeejayRampay 11y ago
        In the general sense I am absolutely after a faster Ruby. I am also after a Ruby with better tooling, better error handling and all bells and whistles. I'm following your development on Ruby Truffle with a lot of excitement, but like most Ruby / Ruby on Rails developers, the only thing that I wish is that I can just switch the Ruby and have it work exactly the same, except faster/better/stronger. From what I understand JRuby/Truffle is closing the gaps at a nice pace (your recent tweets on constant folding is even showing that you're aiming not only for feature parity but for feature parity AND MOAR and that's awesome), but with existing applications and associated gems and all the implication of having to switch my Ruby to another slightly more exotic one, the thought is currently a source of anguish (because a lot of the existing ecosystem is extremely tied and tailored to MRI for better of for worse). I'm simply waiting for the time where I can just replace a line in my Gemfile and reap the benefits. That being said, I would like to thank you for all the efforts you're putting in this, the blog entries, the Ruby Bibliography and all its promising research on making the Ruby ecosystem better, the benchmarks and overall collaboration with the folks at JRuby and I hope we get to see lots of good things in the future from your end.
        chrisseaton 11y ago
        Yeah we're going for being indistinguishable from MRI (unless you want to use the extra features). We even have a simple statically linked build that does not require a JVM, so that you're just running a simple binary like in MRI. That coupled with our support for MRI's C extensions is our strategy for MRI compatibility.
      - technion 11y ago
        Are you able to give us an update on the status of Truffle? The page you linked talks about 2014. The JRuby wiki states: Truffle is a research project, there is no expected release date Overall, it's an exciting project, "Ruby is slow" is an overused meme that's caused a lot of issue for me.
        chrisseaton 11y ago
- matthewmacleod 11y ago
  I'm not sure that would have been a solution. Twitters problems are architectural, telecoms-scale ones. Rails is unlikely to ever be suited for problems like that, and it feels like any attempt to make it so would neuter some of the benefits it offers elsewhere. On the other hand, PHP is just a language and doesn't enforce architectural style. A much better option for this sort of thing, IMO.
- taf2 11y ago
  They did do a lot of work towards improving ruby performance remember this post: https://blog.twitter.com/2011/building-faster-ruby-garbage-collector https://blog.twitter.com/2011/building-faster-ruby-garbage-c... I think a big issue was at the time mainstream ruby was 1.8 and upcoming versions 1.9/2 would later replace and create a minor python2/python3 type issue where many later organizations using ruby 1.8 did not upgrade to 1.9/2 not until just recently, causing a kind of stall in patches contributions to what is now 2.2 That said many of the ideas from twitters work and others is now in ruby.
- pjmlp 11y ago
  Just use Crystal instead.
  - VeejayRampay 11y ago
    Thanks a lot for the heads up on Crystal. The language looks close enough to Ruby that I immediately feel home, yet looks slightly different (and somewhat lower-level it seems).
    - pjmlp 11y ago
      Check the Poly Conf 2015 presentations (sorry cannot search for the link right now) Lots of Ruby code can even be compiled as is.
elktea 11y ago
Interesting you're considering Hack. Does Hack fix all the weird warts PHP has carried into this century?
- amenghra 11y ago
  Hack does not fix all the weird warts PHP has given us, there are far too many of those :) It does give you some level of sanity (aka types). It also gives you tooling (autocompletion, ability to do basic code refactoring, etc.).
  - Cthulhu_ 11y ago
    And yet, there's plenty of other, existing, proven languages out there that have had types and those tooling (beyond the 'basic') out there. I'm not looking for a language battle here, but is inventing your own language based on your favorite language to bring common features from other language really such a good idea?
    - amenghra 11y ago
      If you have an existing codebase in PHP, Hack provides a backwards compatible way to improve the state of things. I have experienced both cases: a conversion of a large codebase from php to Hack and also a conversion from php to rails. Pick the right tool for the right job.
      - justthistime_ 11y ago
        That sounds like a horrible idea in both cases ...
    - joesmo 11y ago
      > I'm not looking for a language battle here, but is inventing your own language based on your favorite language to bring common features from other language really such a good idea? It worked wonders for C++.
- alexbilbie 11y ago
joesmo 11y ago
Nice. The 2-3x improvement is about the same that I've seen in preliminary tests with HHVM on a JSON API in ZF2. There are still many extensions that are not ported at all, something Box didn't run into but I have. These are lesser known extensions, but they can throw a wrench in the migration works. I would definitely check the status of all extensions and as the article mentions, test their code most extensively. My biggest problem still is getting xDebug working with HHVM, something that after a few days of trying I have given up on once again (as of a couple of months ago). Unfortunately, a procedural or OOP language without a proper debugger (hphpd doesn't count) is pretty useless for real-word development. I know the HHVM team is constantly working on improving the ecosystem, so hopefully at some point, we'll have a real debugger that runs without crashing. Once that happens, I can definitely see rewriting the sections of the app that use extensions not yet ported to get the app ready for deployment on HHVM. Right now, the only reason we haven't done so is that we do want to compare both HHVM and PHP7 to see which one will yield the best performance.
geerlingguy 11y ago
FYI, PHP 7 (which is in beta status) is close to HHVM now, speed-wise (using Drupal, Wordpress, Symfony, etc.)[1][2], and it also includes many of the features HHVM + Hack added onto PHP in the first place. Not 1:1 feature parity, of course, but a lot of people who were testing/considering a move to HHVM/Hack have reconsidered now that PHP 7 fixes many of the language's pain points. Competition is good! [1] http://kazanir.github.io/profiling/ http://kazanir.github.io/profiling/ [2] http://hhvm.com/blog/9293/lockdown-results-and-hhvm-performance http://hhvm.com/blog/9293/lockdown-results-and-hhvm-performa...

82 points by tomkwok 11y ago

I wish Twitter had pulled a HHVM with Ruby on Rails. I really do cause HHVM's benefits for PHP-based code bases looks appealing.

ciupicri 11y ago
Hasn't Twitter switched to Scala?
- draven 11y ago
  They certainly seem to have a lot of infrastructure running on the JVM (both Scala and Java.) There is some information there (with emphasis on Scala, obviously): http://www.typesafe.com/resources/case-studies-and-stories/new-tweets-per-second-record-and-how http://www.typesafe.com/resources/case-studies-and-stories/n...
- VeejayRampay 11y ago
  They have for at least parts of their infrastructure but there was a time where they were heavily invested in Ruby on Rails just like Facebook and PHP. They could have chosen to work on the framework and Ruby itself to make things better, they chose to move on to greener pastures instead. As a Ruby developer I regret that didn't "pull a HHVM", would have made my life easier, just HHVM and the whole FB/HHVM/Hack ecosystem is making PHP devs' life easier.
  - chrisseaton 11y ago
    Are you just after a faster Ruby? We're working on an implementation of Ruby that is often an order of magnitude faster than anything else out there http://www.chrisseaton.com/rubytruffle/ http://www.chrisseaton.com/rubytruffle/. Or is it the typing and other infrastructure you wanted?
    - VeejayRampay 11y ago
      In the general sense I am absolutely after a faster Ruby. I am also after a Ruby with better tooling, better error handling and all bells and whistles. I'm following your development on Ruby Truffle with a lot of excitement, but like most Ruby / Ruby on Rails developers, the only thing that I wish is that I can just switch the Ruby and have it work exactly the same, except faster/better/stronger. From what I understand JRuby/Truffle is closing the gaps at a nice pace (your recent tweets on constant folding is even showing that you're aiming not only for feature parity but for feature parity AND MOAR and that's awesome), but with existing applications and associated gems and all the implication of having to switch my Ruby to another slightly more exotic one, the thought is currently a source of anguish (because a lot of the existing ecosystem is extremely tied and tailored to MRI for better of for worse). I'm simply waiting for the time where I can just replace a line in my Gemfile and reap the benefits. That being said, I would like to thank you for all the efforts you're putting in this, the blog entries, the Ruby Bibliography and all its promising research on making the Ruby ecosystem better, the benchmarks and overall collaboration with the folks at JRuby and I hope we get to see lots of good things in the future from your end.
      - chrisseaton 11y ago
        Yeah we're going for being indistinguishable from MRI (unless you want to use the extra features). We even have a simple statically linked build that does not require a JVM, so that you're just running a simple binary like in MRI. That coupled with our support for MRI's C extensions is our strategy for MRI compatibility.
    - technion 11y ago
      Are you able to give us an update on the status of Truffle? The page you linked talks about 2014. The JRuby wiki states: Truffle is a research project, there is no expected release date Overall, it's an exciting project, "Ruby is slow" is an overused meme that's caused a lot of issue for me.
      - chrisseaton 11y ago
matthewmacleod 11y ago
I'm not sure that would have been a solution. Twitters problems are architectural, telecoms-scale ones. Rails is unlikely to ever be suited for problems like that, and it feels like any attempt to make it so would neuter some of the benefits it offers elsewhere. On the other hand, PHP is just a language and doesn't enforce architectural style. A much better option for this sort of thing, IMO.
taf2 11y ago
They did do a lot of work towards improving ruby performance remember this post: https://blog.twitter.com/2011/building-faster-ruby-garbage-collector https://blog.twitter.com/2011/building-faster-ruby-garbage-c... I think a big issue was at the time mainstream ruby was 1.8 and upcoming versions 1.9/2 would later replace and create a minor python2/python3 type issue where many later organizations using ruby 1.8 did not upgrade to 1.9/2 not until just recently, causing a kind of stall in patches contributions to what is now 2.2 That said many of the ideas from twitters work and others is now in ruby.
pjmlp 11y ago
Just use Crystal instead.
- VeejayRampay 11y ago
  Thanks a lot for the heads up on Crystal. The language looks close enough to Ruby that I immediately feel home, yet looks slightly different (and somewhat lower-level it seems).
  - pjmlp 11y ago
    Check the Poly Conf 2015 presentations (sorry cannot search for the link right now) Lots of Ruby code can even be compiled as is.

elktea 11y ago

Interesting you're considering Hack. Does Hack fix all the weird warts PHP has carried into this century?

amenghra 11y ago
Hack does not fix all the weird warts PHP has given us, there are far too many of those :) It does give you some level of sanity (aka types). It also gives you tooling (autocompletion, ability to do basic code refactoring, etc.).
- Cthulhu_ 11y ago
  And yet, there's plenty of other, existing, proven languages out there that have had types and those tooling (beyond the 'basic') out there. I'm not looking for a language battle here, but is inventing your own language based on your favorite language to bring common features from other language really such a good idea?
  - amenghra 11y ago
    If you have an existing codebase in PHP, Hack provides a backwards compatible way to improve the state of things. I have experienced both cases: a conversion of a large codebase from php to Hack and also a conversion from php to rails. Pick the right tool for the right job.
    - justthistime_ 11y ago
      That sounds like a horrible idea in both cases ...
  - joesmo 11y ago
    > I'm not looking for a language battle here, but is inventing your own language based on your favorite language to bring common features from other language really such a good idea? It worked wonders for C++.
alexbilbie 11y ago

joesmo 11y ago

Nice. The 2-3x improvement is about the same that I've seen in preliminary tests with HHVM on a JSON API in ZF2. There are still many extensions that are not ported at all, something Box didn't run into but I have. These are lesser known extensions, but they can throw a wrench in the migration works. I would definitely check the status of all extensions and as the article mentions, test their code most extensively. My biggest problem still is getting xDebug working with HHVM, something that after a few days of trying I have given up on once again (as of a couple of months ago). Unfortunately, a procedural or OOP language without a proper debugger (hphpd doesn't count) is pretty useless for real-word development. I know the HHVM team is constantly working on improving the ecosystem, so hopefully at some point, we'll have a real debugger that runs without crashing. Once that happens, I can definitely see rewriting the sections of the app that use extensions not yet ported to get the app ready for deployment on HHVM. Right now, the only reason we haven't done so is that we do want to compare both HHVM and PHP7 to see which one will yield the best performance.

geerlingguy 11y ago

FYI, PHP 7 (which is in beta status) is close to HHVM now, speed-wise (using Drupal, Wordpress, Symfony, etc.)[1][2], and it also includes many of the features HHVM + Hack added onto PHP in the first place. Not 1:1 feature parity, of course, but a lot of people who were testing/considering a move to HHVM/Hack have reconsidered now that PHP 7 fixes many of the language's pain points. Competition is good! [1] http://kazanir.github.io/profiling/ http://kazanir.github.io/profiling/ [2] http://hhvm.com/blog/9293/lockdown-results-and-hhvm-performance http://hhvm.com/blog/9293/lockdown-results-and-hhvm-performa...