Live data from Hacker News

Node.js in Flame Graphs

techblog.netflix.com

231–240 of 259 posts

Re: Node.js in Flame Graphs

#231

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…

Regexps with backtracks are not regular languages (IIRC, right?), does that matter here?

That's right. Typical routing regexes will not use backreferences, so that's not really an issue here. However, most routes do have parameters implemented as capture groups (which, I believe, is also not technically a feature of regular expressions). One simple solution would be to use a big regex (the union of all the routes) to determine which route it is (in O(n) time), and then once you know the route, use another regex to parse the parameters in the URL. So each route lookup requires 2 regex matches rather than N.

Re: Node.js in Flame Graphs

#232
Would someone explain what I'm missing about the flame graphs? Why are they indispensable here? In a normal profiler, you'd just expand the hot path and see what had the most samples. Apart from making recursion very explicit, what special aspect do flame graphs expose?

Re: Node.js in Flame Graphs

#233
post #132

Earlier quoted context omitted.

Ok you add a new route but how do you reference what code should be executed when that route is hit?

We have something that loads up, via requires, the action (or route) that should be run when a URL is encountered.

Second dmak, would love to understand more. I can following dynamically loading routes but can't follow how that would be implemented end to end. Some things I would be interested in: - Where do the keep the code that gets executed for new routes? Is that deployed dynamically as well? - If you are changing routes dynamically how do you test in non-prod, are you constantly syncing non prod with prod? - How do you control what you deploy dynamically vs what you migrate through the environments?

Re: Node.js in Flame Graphs

#234

Earlier quoted context omitted.

I agree with you that the greatest strength of open source is that you can just go read the code and (optionally) fix it. Netflix did this and it got them past their crisis. I think you missed my point though, which was that there isn't any sort of fitness function being applied to open source. In the closed source environment that it 'price' (caveat walled gardens). By paying for the software customers "vote with th…

There totally is a fitness function for open-source. People who find that an open-source program creates more hassles than it solves don't use it. Folks who blog about their hassles induce other people not to use it. There are a number of open-source projects - web.py, Mongo, Angular, Ember - that I am actively avoiding because IMHO their benefits to me don't outweigh risks or previous hassles experienced. Much bette…

> People who find that an open-source program creates more hassles than it solves don't use it.

But bad open-source software can live on to upset the productive lives of others forever, as the distribution cost is essentially free. With bad closed-source software, if the producer goes out of business (without a buyer), typically it becomes unavailable.

Re: Node.js in Flame Graphs

#235
post #9
post #3

This is the first I've heard of restify, but it seems like a useful framework for the main focus of most Node developers I know, which is to replace an API rather than a web application.

You're going to love restify. We use it at TrackIf and can't imagine our API running on anything else. Couple it with Swagger and you won't be looking back :-)

[deleted]

Re: Node.js in Flame Graphs

#236
post #67

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…

One more advantage of Node.js over Java is that development is much faster with Node.js.

Re: Node.js in Flame Graphs

#237

Earlier quoted context omitted.

There totally is a fitness function for open-source. People who find that an open-source program creates more hassles than it solves don't use it. Folks who blog about their hassles induce other people not to use it. There are a number of open-source projects - web.py, Mongo, Angular, Ember - that I am actively avoiding because IMHO their benefits to me don't outweigh risks or previous hassles experienced. Much bette…

> People who find that an open-source program creates more hassles than it solves don't use it. But bad open-source software can live on to upset the productive lives of others forever, as the distribution cost is essentially free. With bad closed-source software, if the producer goes out of business (without a buyer), typically it becomes unavailable.

This is both a feature and a bug. It is definitely caveat emptor; you should do your diligence before pulling in any piece of third-party software. However, there are many, many critical systems that incorporate unmaintained open-source libraries. libxml, for example, gets a bugfix release about every year, while TeX has been asymptotically approaching version pi since 1989. That's fine; those libraries are stable, they do what they do, and I'd much rather have them available than have them disappear like closed-source alternatives.

Re: Node.js in Flame Graphs

#238
post #14

Earlier quoted context omitted.

I flagged it as Offtopic. But it is correct. "Learnings" is at best a pointless affectation, like saying "utilised" instead of "used". At worst, according to the OED, it's not even a word. http://english.stackexchange.com/questions/19227/plural-of-l... Also: http://www.merriam-webster.com/dictionary/learning No plural option.

Continuing the OT and heedless of the downvotes: I appreciate your efforts, but they can't help themselves -- so many people love using recently invented (and redundant) words because they think it makes them sound smart and hip. Sorta like people who think JS is an amazing language and love to sell that point of view.

I think their must be a voting ring of marketers that are upset their latest buzzword-bingo entry has been called out :-)

Re: Node.js in Flame Graphs

#239
post #67

Earlier quoted context omitted.

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…

One more advantage of Node.js over Java is that development is much faster with Node.js.

No, just please no. Any moderately competent programmer can be productive in either Java or Javascript (+ Node.js). Javascript may help incompetent programmers feel productive because Javascript has fewer compile-time constraints but in the long run the cost of maintaining code written by an incompetent more than counteracts any perceived benefit that Javascript offers.

Re: Node.js in Flame Graphs

#240

Earlier quoted context omitted.

SVGs can contain ECMAScript, video, canvases, animation, all sorts of things. They're the replacement for Flash that nobody seems to use.

Well, there was a good reason for that, for a long time: IE didn't even begin to support .svg until version 9, which means that it isn't a realistic option for deployment for anyone who needs to support pre-evergreen browsers. I investigated them a year or two or so ago, because I found that AngularJS could work quite nicely within an .svg document, which opened up some exciting possibilities. My recollection is that…

And IE still doesn't (nor do they plan to) support declarative animation in SVGs. (SMIL) Someone there decided that script based animation is more robust so they just bypassed that capability. I think it's a terrible idea because you forego having tightly integrated SVG animation modules that can just be dropped in as needed.
Post reply on HN