Page MenuHomePhabricator

Offer io.js on Jessie
Closed, ResolvedPublic

Description

Initial benchmarks with Parsoid and RESTBase indicate a 10-15% speedup from the newer v8 version shipped in iojs. It also efficiently supports modern ES6 language features like native promises, generators, collections, classes, arrow functions or template expressions. See https://github.com/lukehoban/es6features for a good overview. Especially generators can potentially make our async code quite a bit more readable, and are on track to become even prettier with async and await.

As soon as there are decent Debian packages for iojs we should IMHO seriously consider upgrading our nodejs stack. We are already routinely testing Parsoid and RESTBase against iojs via travis, and have not seen any issues.

Regarding nodejs 0.12 vs. iojs: just from looking at https://github.com/iojs/io.js/graphs/contributors vs. https://github.com/joyent/node/graphs/contributors I think it's fair to say that the momentum has shifted significantly towards iojs. Node 0.12 ships with versions of v8 (3.28) and libuv that are out of date / no longer supported by upstream. The platforms remain highly compatible (important features like generators are also available in 0.12, albeit slower), so the risk of choosing the faster implementation while the longer-term node roadmap sorts itself out seems to be limited.

The iojs Debian packages are called 'iojs', and provide nodejs if installed. This means that we can offer iojs along with Node, which lets us upgrade clusters individually, with nothing changing by default.

Event Timeline

GWicke raised the priority of this task from to Low.
GWicke updated the task description. (Show Details)
GWicke added a subscriber: GWicke.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 7 2015, 1:50 AM
GWicke updated the task description. (Show Details)Mar 7 2015, 1:54 AM
GWicke set Security to None.
GWicke edited subscribers, added: cscott, ssastry, mobrovac and 7 others; removed: Aklapper.

There are jessie iojs packages from nodesource:

sources.list lines for jessie:

deb https://deb.nodesource.com/iojs_1.x jessie main
deb-src https://deb.nodesource.com/iojs_1.x jessie main

They are based on Chris Lea's Ubuntu packages, which we have used for 0.10 testing in the past. This means that they differ from Debian 0.10 packages by not building a separate npm package.

GWicke moved this task from Backlog to Unnamed Column on the Services board.Mar 17 2015, 8:06 PM
Ricordisamoa renamed this task from Lets consider upgrading our nodejs installs to iojs (once decent Debian packages are ready) to Lets consider upgrading our Node.js installs to io.js (once decent Debian packages are ready).Apr 16 2015, 6:32 PM
Ricordisamoa awarded a token.
Ricordisamoa added a subscriber: Ricordisamoa.

I think it's worth considering the upgrade for our Jessie installs. That would avoid affecting any older services including Parsoid or those on the sca cluster.

I would strongly recommend against Wikimedia adopting io.js at this time.

To think it'll just be a performance boost with happy ending is naïve. There will be additional maintenance overhead and inherent stability/upkeep cost. I don't believe we have resources to worry about that.

The project more or less started as a dare because Joyent wasn't maintaining Node.js well. However, many people involved with io.js are also involved with Node.js. It's unclear to me whether they were blocked by Joyent or just principally unwilling to continue. It relates to their demand for an open governance model. After no satisfactory response to that demand, part of the community forked and created io.js. The project is immature at this point. (Started a few months ago, in January 2015.) It seems irresponsible to run in production.

Since then, a lot happened. There's an enormous amount of discussion and restructuring going on. Here's a summary of just one week of activity (April 3rd in this case): https://medium.com/node-js-javascript/io-js-week-of-april-3rd-a4e1fe0c38c1#d576

It has no corporate backing at this point (does this matter?). They're still figuring out whether to join the newly created Node.js Foundation, or to start their own foundation etc.

It's also worth thinking about the signal we'd be sending to the world. Wikimedia Foundation has a voice. Do we want it to speak encouragement of io.is? Or should we stick to boring Node.js and give them time to figure it out first? Personally I expect them to reconcile. Because, unlike the Blink/WebKit fork, there are no major technical disagreements on what the software platform should look like.

Also note that Node.js has received several releases since January 2015 and the repository seems to be picking up pace slowly. Including pull requests from io.js. And many of the same people involved with io.js contributing to Node.js still.

Excuse my brevity, but please know that I neither oppose nor support io.js, I don't know enough about the situation around its governance model at this point. It seems io.js made some good points. But my argument is not based in that.

GWicke added a comment.EditedApr 16 2015, 9:35 PM

@Krinkle, you seem to be more concerned about naming & the political situation. I don't think that those aspects matter that much. Node 0.12 and iojs remain broadly compatible. In fact, we have been testing each commit against both for a while now. Your assertion that node 0.12 is more stable or reliable requires a citation. We have not seen such a difference in practice.

I think it is also safe to say that we can use whichever project emerges victorious next without significant trouble, be that node 0.14 or iojs. We'll continue testing all our projects against both. Lets make our decision on technical grounds, without worrying too much about politics or FUD.

At the technical level, iojs does have more mature support of ES6 features:

  • only exposes stable ES6 features by default, compared to node 0.12 exposing all of them (incl. unfinished ones) with --harmony
  • uses a more mature & supported version of v8

It is thus a better option for carefully adopting stable ES6 features. This lets us reduce our reliance on ES6 shims, which is good for reliability and performance. We are widely using ES6 collections, Promises, Object.assign and others, all implemented in shims.

Will Node.js continue to be supported for non-WMF installations?

GWicke added a comment.EditedApr 17 2015, 12:42 AM

@tstarling: Generally yes, for reasonably recent versions. RESTBase is supporting & running CI against Node.js 0.10, 0.12 and iojs. Parsoid is still supporting 0.8 as well, but is just deprecating that.

For the most part, shims will keep things working on older node versions, at the cost of performance. For some projects we might elect to use generators, which are only natively supported in Node 0.12 with --harmony parameter and iojs. However, we could still make those work on 0.10 and probably even 0.8 using the babeljs transpiler.

GWicke updated the task description. (Show Details)Apr 17 2015, 11:31 PM
Ricordisamoa renamed this task from Lets consider upgrading our Node.js installs to io.js (once decent Debian packages are ready) to Let's consider upgrading our Node.js installs to io.js (once decent Debian packages are ready).Apr 17 2015, 11:34 PM

@GWicke Experimental or non-default flags like --harmony are not practical requirements for stable release of our software; such flags are not supported by the package.json engine specification. I would recommend making sure that RESTBase and Parsoid work properly under Node 0.12 from a regular npm dependency.

Similar to what CoffeeScript packages do. That means any ES6 syntax not supported by Node 0.12 by default would have to be compiled by Parsoid (not the customer) using an npm preinstall or prepublish hook.

GWicke renamed this task from Let's consider upgrading our Node.js installs to io.js (once decent Debian packages are ready) to Offer io.js on Jessie.Apr 21 2015, 8:39 PM

Note that coffeescript packages are typically not handled "properly" by npm, either -- they depend on require('coffeescript') being included first, which then "teaches" npm how to load .coffee files. Packages which require --harmony or babeljs support would be analogous.

I think you are dismissing --harmony inappropriately. It is not an experimental flag. It's more akin to, say, using python3 instead of python2. The shbang at the top of the file tells you which version of the language to use. Nobody uses npm's "engine" flag in package.json; requiring that to have some syntax for --harmony is inappropriate.

It should also be noted that io.js is a "friendly fork" of node.js, with the expectation that they will resync in the future. And they are both chasing v8, which is chasing the ES6 language spec (just made final this month). So it's not like we're actually going to get multiple language variants here: everyone's running toward the same point, it's just that io.js is getting there a bit more quickly these days.

iojs is about to release v2.0.0. So that might be a good target for a "stable" version to install on the WMF machines. On the other hand, the recent v1.8.1 release is not expected to differ that much from v2.0.0. See https://github.com/iojs/io.js/issues/1436 for some inside-baseball release-planning details.

GWicke added a comment.EditedMay 14 2015, 4:44 AM

Today iojs joined the node foundation, and it sounds like the iojs branch will be the basis for ongoing node.js development: "The new "converged" node project will begin with io.js master and port changes from node.js in for its first release target."

So, current iojs 2.0 will be followed by iojs/node 3.0.

GWicke raised the priority of this task from Low to Medium.Jun 19 2015, 10:41 PM
Restricted Application added a subscriber: Matanya. · View Herald TranscriptJul 14 2015, 5:26 PM
GWicke added a comment.EditedJul 14 2015, 5:39 PM

On IRC, @MoritzMuehlenhoff proposed to wait until LTS comes out in October.

We could do that, but it would be nice to start gradually migrating to modern v8 sooner. We know that several of our services (including Parsoid and RESTBase) are compatible with modern v8, and perform better with it. We have been testing each restbase commit against iojs in the last six months, without running into issues.

Right now the iojs debs are still named 'iojs', which makes it fairly easy to install them instead of nodejs on specific hosts, and thus gradually migrate one service at a time. Once iojs / node 3 LTS is out, we'll probably have to do some manual package tweaking to avoid replacing node 0.10 everywhere at once.

There doesn't seem to be any activity wrt packaging io.js in Debian (and the already existing nodejs is already poorly maintained). As much as I dislike using external, vendor-provided debs/apt sources, in this case we're better off with the packages from nodesource.

GWicke added a comment.EditedJul 24 2015, 7:16 PM

@MoritzMuehlenhoff, what would it take to import those packages?

I'd really love to be finally able to use those performance improvements in HTTP parsing I contributed upstream over a year ago. The new v8 version should speed up CPU-intense services like Parsoid on the order of 15%. That's over a second on large pages like [[Barack Obama]].

We can surely add them for now so that you can experiment/test with it, I can do that this week.

We can surely add them for now so that you can experiment/test with it, I can do that this week.

I have imported 1.8.4 for jessie-wikimedia (iojs and iojs-dbg)

Note that these are not co-installable with nodejs from jessie (the iojs packages declare a Conflicts: with nodejs).

I have imported 1.8.4 for jessie-wikimedia (iojs and iojs-dbg)

Ohh, thank you!

Small nit: The current stable version is 2.5.0:

https://deb.nodesource.com/iojs_2.x/pool/main/i/iojs/

It would be great if we could go straight to that version.

I have imported 2.5.0 for jessie-wikimedia (iojs and iojs-dbg)

GWicke closed this task as Resolved.Aug 3 2015, 3:06 PM
GWicke claimed this task.

@MoritzMuehlenhoff: Thanks again, this is great!