Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js in Flame Graphs

techblog.netflix.com

Post reply on HN
Print view View original

71–80 of 259 posts

Re: Node.js in Flame Graphs

#71

Post by Terr_ »

yourad_io wrote: post #39
remon wrote: post #21

I wonder what the thought process was behind moving their web service stack (partially?) to node.js in the first place. For a company with the scale and resources of Netflix it's not exactly an obvious choice.

What are the arguments against node.js in their use case? Not looking to start any wars, but I was under the impression that if you know what you're doing* node.js is pretty awesome. This particular bug had to do with a misunderstanding regarding the express API. * for the most part: understand async and closures/memory leaks.

I was doing some googling about this earlier, IIRC one of the big ones was "Good when your bottleneck is I/O, not good when your bottleneck is CPU."

Re: Node.js in Flame Graphs

#73

Post by plorkyeran »

andrewvc wrote: post #36
thedufer wrote: post #10

> It’s unclear why Express.js chose not to use a constant time data structure like a map to store its handlers. Its actually quite clear - most routes are defined by a regex rather than a string, so there is no built-in structure (if there's a way at all) to do O(1) lookups in the routing table. A router that only allowed string route definitions would be faster but far less useful. I can't explain away the recursion…

A lot of people here are right, the right way is with an NFA. I just want to add that the solution is not even hard, you can do it with string concatenation and capture groups using regexps. Regexps are NFAs, and are highly optimized C code in just about every JS engine. If I have the routes /foo/bar and /foo/bar/(\d+) I can generate the regexp ((^\/foo\/bar$)|(^\/foo\/bar\/\d+$)) I'm not at all surprised, the qualit…

Given that combined regex, how do you determine which of the routes that went in to it was the one that matched?

Re: Node.js in Flame Graphs

#74

Post by Terr_ »

codelucas wrote: post #58

> This turned out be caused by a periodic (10/hour) function in our code. The main purpose of this was to refresh our route handlers from an external source. This was implemented by deleting old handlers and adding new ones to the array. Unfortunately, it was also inadvertently adding a static route handler with the same path each time it ran. I don't understand the need of refreshing route handlers. Could someone ex…

It sounds to me like some kind of configuration/IT-infrastructure-control issue. I wouldn't be surprised if it relates to some sort of "we want a way to toggle this live without an actual code-push" narrative.

Re: Node.js in Flame Graphs

#76

Post by remon »

Terr_ wrote: post #71
yourad_io wrote: post #39

Earlier quoted context omitted.

What are the arguments against node.js in their use case? Not looking to start any wars, but I was under the impression that if you know what you're doing* node.js is pretty awesome. This particular bug had to do with a misunderstanding regarding the express API. * for the most part: understand async and closures/memory leaks.

I was doing some googling about this earlier, IIRC one of the big ones was "Good when your bottleneck is I/O, not good when your bottleneck is CPU."

I hear this more often and it is somewhat misleading. That sentence seems to imply node.js is better in terms of I/O throughput compared to other technologies, as if it's a trade off. This is incorrect and it would be more accurate to say "Good enough when your bottleneck is I/O, not good when your bottleneck is CPU.".

Re: Node.js in Flame Graphs

#77

Post by yourad_io »

remon wrote: post #67
yourad_io wrote: post #51

Earlier quoted context omitted.

To give some arguments in favour: - "Here we see our latencies drop down to 1 ms and remain there after we deployed our fix." - They can hire from a vastly larger pool of developers. Since they've got both budget and brand recognition, they should have no problems hiring high end JS guys & gals.

Why are these arguments in favor of Node.js over their current Java based stack? Java is both considerably more speedy for this sort of workload and there's a significantly larger pool of high end Java server developers compared to high end JavaScript server developers. Budget and brand recognition are not necessarily in favor of node.js over other stacks. That simply helps with getting the better engineers in genera…

They are arguments in favor of node.js being a reasonable tool for the job.

> Java is both considerably more speedy for this sort of workload

They're quoting 1ms latencies, that's pretty speedy. Maybe Java could do > there's a significantly larger pool of high end Java server developers compared to high end JavaScript server developers

Oh, I would have thought there are far more JS* folks out there than Java.

> Budget and brand recognition are not necessarily in favor of node.js over other stacks. That simply helps with getting the better engineers in general.

That's what I meant - them being in favour of Netflix as an employer - they aren't "Bob's Digital Agency" so they can have their pick of the litter of node devs.

* I'm not sure if the "server" distinction is meaningful here - if you know JS, you know node.js - simply a matter of familiarizing yourself with node-specific APIs.

Re: Node.js in Flame Graphs

#78

Post by wpietri »

From the article:

> What did we learn from this harrowing experience? First, we need to fully understand our dependencies before putting them into production.

Is that the lesson to learn? That scares me, because a) it's impossible, and b) it lengthens the feedback loop, decreasing systemic ability to learn.

The lesson I'd learn from that would be something like "Roll new code out gradually and heavily monitor changes in the performance envelope."

Basically, I think the approach of trying to reduce mean time between failure is self-limiting, because failure is how you learn. I think the right way forward for software is to focus on reducing incident impact and mean time to recovery.

Re: Node.js in Flame Graphs

#79

Post by baudehlo »

plorkyeran wrote: post #73
andrewvc wrote: post #36

Earlier quoted context omitted.

A lot of people here are right, the right way is with an NFA. I just want to add that the solution is not even hard, you can do it with string concatenation and capture groups using regexps. Regexps are NFAs, and are highly optimized C code in just about every JS engine. If I have the routes /foo/bar and /foo/bar/(\d+) I can generate the regexp ((^\/foo\/bar$)|(^\/foo\/bar\/\d+$)) I'm not at all surprised, the qualit…

Given that combined regex, how do you determine which of the routes that went in to it was the one that matched?

If it matched the first, match[2] is set. If it matched the second, match[3] is set.

Or you use a better regexp library than the default JS one and use named captures.

Re: Node.js in Flame Graphs

#80

Post by baudehlo »

jdmichal wrote: post #46
TheLoneWolfling wrote: post #13

> benchmarking revealed merely iterating through each of these handler instances cost about 1 ms of CPU time 1ms / entry? What is it doing that it's spending 3 million cycles on a single path check?

Running (uncompiled?) regular expressions, it seems.

V8 compiles regular expressions to machine code.
Post reply on HN