Node.js in Flame Graphs • Hacker News Board

Re: Node.js in Flame Graphs

#101

Post by yourad_io » Wed, Nov 19, 2014, 6:58 PM UTC

yourad_io wrote: post #91

Terr_ wrote: post #71

Earlier quoted context omitted.

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."

> "not good when your bottleneck is CPU" 99% of cases, your bottleneck will be I/O. In the 1% of cases where your webserver's bottleneck is the CPU, you have much bigger problems than using a hipster ;) language: you're doing it wrong (tm) on an architectural level: (a) Your processor-intensive/long-running tasks need to be in seperate worker processes and (b) you need more webserver instances. I usually try to avoid…

I shouldn't have tried to be funny on HN* . For this I apologize.

Can I get a rebuttal to my points along with the downvotes, though?

Is someone disputing that CPU intensive tasks should be moved off the webserver?

Have you personally had experiences where your honest-to-$deity webserver bottleneck was the CPU? I'd be incredibly surprised. In most cases I'd guess you're underprovisioned and/or badly architected.

* This is where we come to somberly discuss interesting things.

Re: Node.js in Flame Graphs

#102

Post by [deleted] » Wed, Nov 19, 2014, 6:59 PM UTC

thedufer wrote: post #92

andrewvc wrote: post #84

Earlier quoted context omitted.

First off, you don't need to handle the 'multiple' case, since the "|" has precedence rules applied to it. The leftmost match is the match. Second, you know which one matched based on the index of the capture groups, which is deterministic. See this example: http://rubular.com/r/HiW6gjnURe You could write a simple router based on this in < 50 lines of JS. I'd do it now, but I have work to do.

> First off, you don't need to handle the 'multiple' case, since the "|" has precedence rules applied to it. Read my top-level post again - multiple routes can be called on the same request, so express has to be able to find all of the matches, not just the first one. This is a mistake in the original article, as the author doesn't appear to understand the power of express routers. > Second, you know which one matche…

[deleted]

Re: Node.js in Flame Graphs

#103

Post by andrewvc » Wed, Nov 19, 2014, 7:01 PM UTC

thedufer wrote: post #92

andrewvc wrote: post #84

Earlier quoted context omitted.

First off, you don't need to handle the 'multiple' case, since the "|" has precedence rules applied to it. The leftmost match is the match. Second, you know which one matched based on the index of the capture groups, which is deterministic. See this example: http://rubular.com/r/HiW6gjnURe You could write a simple router based on this in < 50 lines of JS. I'd do it now, but I have work to do.

> First off, you don't need to handle the 'multiple' case, since the "|" has precedence rules applied to it. Read my top-level post again - multiple routes can be called on the same request, so express has to be able to find all of the matches, not just the first one. This is a mistake in the original article, as the author doesn't appear to understand the power of express routers. > Second, you know which one matche…

Ah, I did miss that, but it does still work. Run the following code below, you'll see multiple groups match.

    "/foo/bar/3".match(/((^\/foo\/bar\/.*)|(^\/foo\/bar\/(\d+)$)|(^\/baz))/) =>

Additionally, parsing out the number of capture groups in a regexp is simple, just looked for unescaped paren groups. You can do it once at route definition.

Re: Node.js in Flame Graphs

#104

Post by exratione » Wed, Nov 19, 2014, 7:02 PM UTC

The express router array is pretty easy to abuse, it's true. For example, as something you probably shouldn't ever do:

https://www.exratione.com/2013/03/nodejs-abusing-express-3-t...

I guess the Netflix situation is one of those that doesn't occur in most common usage; certainly dynamically updating the routes in live processes versus just redeploying the process containers hadn't occurred to me as a way to go.

Re: Node.js in Flame Graphs

#105

Post by cdoxsey » Wed, Nov 19, 2014, 7:02 PM UTC

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…

Most routes are prefix matches, so a trie (or one of its variants) would work well.

Re: Node.js in Flame Graphs

#106

Post by [deleted] » Wed, Nov 19, 2014, 7:03 PM UTC

mjr578 wrote: post #30

BradRuderman wrote: post #20

Why are they loading in routes from an external source? Is that normal, I have never seen that before.

We like the option of dynamically loading new routes, that point to new endpoints. We also have the ability to release new versions of our UI without redeploying (or restarting) our servers.

[deleted]

Re: Node.js in Flame Graphs

#107

Post by [deleted] » Wed, Nov 19, 2014, 7:03 PM UTC

mjr578 wrote: post #30

BradRuderman wrote: post #20

Why are they loading in routes from an external source? Is that normal, I have never seen that before.

We like the option of dynamically loading new routes, that point to new endpoints. We also have the ability to release new versions of our UI without redeploying (or restarting) our servers.

[deleted]

Re: Node.js in Flame Graphs

#108

Post by BradRuderman » Wed, Nov 19, 2014, 7:03 PM UTC

mjr578 wrote: post #30

BradRuderman wrote: post #20

Why are they loading in routes from an external source? Is that normal, I have never seen that before.

We like the option of dynamically loading new routes, that point to new endpoints. We also have the ability to release new versions of our UI without redeploying (or restarting) our servers.

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

Re: Node.js in Flame Graphs

#109

Post by [deleted] » Wed, Nov 19, 2014, 7:03 PM UTC

mjr578 wrote: post #30

BradRuderman wrote: post #20

Why are they loading in routes from an external source? Is that normal, I have never seen that before.

We like the option of dynamically loading new routes, that point to new endpoints. We also have the ability to release new versions of our UI without redeploying (or restarting) our servers.

[deleted]

Re: Node.js in Flame Graphs

#110

Post by [deleted] » Wed, Nov 19, 2014, 7:03 PM UTC

mjr578 wrote: post #30

BradRuderman wrote: post #20

Why are they loading in routes from an external source? Is that normal, I have never seen that before.

We like the option of dynamically loading new routes, that point to new endpoints. We also have the ability to release new versions of our UI without redeploying (or restarting) our servers.

[deleted]