Doesn't this seem like a bug in the express router? All of the additional routes in the array are dead (can't be routed to).
Node.js in Flame Graphs
11–20 of 259 posts
Re: Node.js in Flame Graphs
#12My biggest takeaway from this article is that Netflix is moving from Express to Restify, and I look forward to watching the massive uptick this has on https://github.com/mcavage/node-restify/graphs/contributors
Re: Node.js in Flame Graphs
#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?
Re: Node.js in Flame Graphs
#14OFFTOPIC: "Today, I want to share some recent learnings from performance tuning this new application stack." The word you want is "lessons".
OFFTOPIC: "Today, I want to share some recent learnings from performance tuning this new application stack." The word you want is "lessons". Jeez, not only is your comment offtopic and pedantic, it's also wrong.
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.
Re: Node.js in Flame Graphs
#15> ...as well as increasing the Node.js heap size to 32Gb. > ...also saw that the process’s heap size stayed fairly constant at around 1.2 Gb. This is because 1.2 GB is the max allowed heap size in v8. Increasing beyond this value has no effect. > ...It’s unclear why Express.js chose not to use a constant time data structure like a map to store its handlers. It it is non-trivial (not possible?) to do this in O(1) for…
> It it is non-trivial (not possible?) to do this in O(1) for routes that use matching / wildcards
I'd be impressed if they did it consistently in O(1) for static routes. I think they were looking for O(log(number of different routes)) instead of O(n).
Re: Node.js in Flame Graphs
#16If I had to pick one line to highlight (not to criticize, but was a wise lesson worth sharing) it would be this one:
"First, we need to fully understand our dependencies before putting them into production."
Re: Node.js in Flame Graphs
#17 > our misuse of the Express.js API was the
> ultimate root cause of our performance issue
Re: Node.js in Flame Graphs
#18> 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…
On the other hand, without the recursion I don't see how the flame graph would have been helpful.
Re: Node.js in Flame Graphs
#19OFFTOPIC: "Today, I want to share some recent learnings from performance tuning this new application stack." The word you want is "lessons".
"learnings" is a perfectly cromulent word: https://books.google.com/ngrams/graph?content=learnings&year...
Nope. You see an option for a plural here? http://www.merriam-webster.com/dictionary/learning
Re: Node.js in Flame Graphs
#20Why are they loading in routes from an external source? Is that normal, I have never seen that before.