Node
https://nodesource.com/blog/node-js-performance-monitoring-part-3-debugging-the-event-loop
https://v8project.blogspot.ca/ https://github.com/v8/v8.dev/blob/45872b0dd2f59ce9ac2d0cf7bbbceb9fa452a87c/src/docs/embed.md
https://github.com/tomato42/tlsfuzzer
- https://strongloop.com/strongblog/how-to-heap-snapshots/
- https://strongloop.com/node-js/node-js-performance-tips/
IBM NodeReport (FFDC for Node.js):
IBM Health Center
https://www.ibm.com/blogs/bluemix/2015/07/how-to-analyze-performance-in-bluemix/
https://developer.ibm.com/node/2016/09/27/advances-in-core-dump-debugging-for-node-js
https://scottfrees.com/ebooks/nodecpp/
https://community.risingstack.com/using-buffers-node-js-c-plus-plus
Not sure how to install these.
- https://developers.google.com/web/tools/chrome-devtools/rendering-tools/js-execution
- https://developers.google.com/web/tools/chrome-devtools/memory-problems/heap-snapshots#view_snapshots
- node.js
git clone git://github.com/iojs/io.js.git <--- guarantee that push is not possible
git clone iojs MERGE-iojs
git config --global --add core.whitespace fix
https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/ https://github.com/iojs/roadmap https://github.com/iojs/website https://github.com/iojs/build https://github.com/iojs/io.js
git shortlog -n -s
- http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxbd00/poll.htm
- http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb500/canc.htm
streams, useful modules (careful attention to error handling):
- pump... does it really handle errors?
- https://github.com/maxogden/mississippi
- duplexify
- end-of-stream:
- http request end/close: end won't happen if client errors (it will come as client_error on the server). close will always happen after socket closes... but there could still be buffered data, so data might keep coming in...
- pump: important replacement for .pipe(), that avoids fd leaks: there is a case to be made that pipe shouldn't show up in production code
- pumpify: pass an array of streams
- readable_stream: always use this, not node core...
- except don't use that...: just use streams that use readable_stream
- streams adventure..., streams handbook... already updated to streams3... but if you are running 0.10 you need to use readable_stream to get streams3
- what happens when an object stream goes into a fs.writestream...
-
sl jekyll...
-
docco
-
jsdoc, w/extras
-
json from jsdoc: https://github.com/visionmedia/dox
-
markdown from dox: https://github.com/codeactual/apidox
-
html from dox: https://github.com/punkave/dox-foundation
-
review of a alternatives to dox:
-
JS:
- sinon
- async to step
- loopback error handling: https://gist.github.com/pulkitsinghal/82e659ca4b56bc1b4b2c
- https://docs.google.com/presentation/d/1H3E2ToJ8VHgZS8eS6bRv-vg5OksObj5wv6gyzJJwOK0/edit#slide=id.p
- https://github.com/tc39/ecma262/pull/473
- http://blog.trevnorris.com/2015/02/asyncwrap-tutorial-introduction.html
- lag and idle, become clear on the terms
- low lag, high idle, either an efficient app, or one that has a bottlneck in the next hopt
- symptom may be people blaming node for not responding well, but its not its fault
XXX http://www.brendangregg.com/perf.html
-
watch the videos
-
http://www.brendangregg.com/blog/2014-09-17/node-flame-graphs-on-linux.html
-
https://github.com/brendangregg/perf-tools/blob/master/examples/cachestat_example.txt
-
study: load tests:
- ab
- gor: https://github.com/bobthecow/gor
- k6: https://k6.io/
-
olegas/node-event-loop-monitor: uses async hooks to monitor loop - this is possible?
-
bretcope/node-gc-profiler
-
easy flamechart generation: https://github.com/davidmarkclements/0x
- perf record node app.js
- node --prof app.js
- 0x -o app.js
-
llnode node -c core
-
http://blog.codeship.com/understanding-garbage-collection-in-node-js
-
https://www.nearform.com/blog/node-js-is-getting-a-new-v8-with-turbofan/
Absorb or record Netflix talk:
-
graph error rate - supervisor would need to publish
-
graph request latencies - agent has these?
-
npm install -g json daggr; also quantize
-
vasync: netflix likes the observability
-
restify:
- prints out the
req.timers
, with times for each middleware handler - request capture stream, captures everything at trace level and above. IFF there is an error, the entire log is dumped, otherwise its discarded
- prints out the
-
memory leaks are hard, they get 2-3 a year, and they take about a week to find, they use mdb to backtrack to find who refs and object. also, they know they have a mem leak right away... ?! from graphs
-
api.netflix.com, all the micro-services bound together
-
mem tracking: gcore PID on linux, scp to a solaris vm, run mdb... restify author knows how, can ask
-
http://www.technology-ebay.de/the-teams/mobile-de/blog/nodejs-real-world
-
https://strongloop.com/strongblog/tips-optimizing-slow-code-in-nodejs
-
https://github.com/strongloop/loopback-boot/issues/167
I could try to fix, using Ben's perf trick.
-
http://www.brendangregg.com/blog/2016-07-13/llnode-nodejs-memory-leak-analysis.html
-
https://sandstorm.io/news/2016-09-30-fiber-bomb-debugging-story
-
http://www.slideshare.net/GireeshPunathil/follow-your-code-node-tracing
So "netstat -tnlp" could be replaced with "ss -tnlp". lsof -i tcp -s tcp:listen More or less what you're looking for as well? Or without nss port name resolution or hostname resolution: lsof -nPi tcp -s tcp:listen
-
https://developer.atlassian.com/blog/2015/10/profiling-node-apps
-
load and perf test TPS
-
promise performance: bluebird faster?
-
tick processor reading:
--trace-opt --trace-deopt --trace-inlining --code-comments
-
strace -c!
-
try to profile LB... can I make it faster?
-
http://techblog.netflix.com/2015/12/debugging-nodejs-in-production.html
-
debugging deep dive: http://nodeup.com/onehundredthirteen
-
http://yunong.io/2015/11/23/generating-node-js-flame-graphs/
-
https://strongloop.com/strongblog/tips-optimizing-slow-code-in-nodejs/
-
Move try-catch to separate function to keep entire function from being deoptimized.
-
Use string concatenation instead of joining an array of strings.
-
--gdbjit
: Ben Noordhuis: sam: a debug build probably won't reveal much more. the stack frames below Runtime_OwnKeys are javascript frames that gdb can't decodeBen Noordhuis: sam: you could try building with
./configure --gdbjit
but you also need to pass--gdbjit
to the worker processBen Noordhuis: or --gdbjit_dump, that writes a core file to /tmp/elfdump${num}.o
Mem leaks:
-
usually in v8 heap, OR buffers
-
buffers: node-buffer inspector, somewhere
-
handles: there is an inspector to print useful info about handles
-
https://github.com/petkaantonov/bluebird/wiki/Optimization-killers
-
example of testing deopt:
try the opt-check techique: on Function.call(x, arguments) vs apply on the weird code in my fs promises make a list of these idioms...
add link to node.js "optimization" section
-
lsof -i tcp -s tcp:listen More or less what you're looking for as well? Or without nss port name resolution or hostname resolution: lsof -nPi tcp -s tcp:listen
The "EPERM" error can result from two conditions:
-
The user genuinely has no access to the file that NPM is trying to manipulate. I think that is very unlikely in this case.
-
When npm tries to move or delete the file, it's open by another process. In most cases this happens because some background process temporarily opens the file for some reason - typically this would be a virus scanner, a synchronization service (e.g. dropbox) or an indexing service (e.g. the windows built-in one).
The rest applies to the second hypothesis:
-
NPM's solution to dealing with EPERM errors on windows is to retry a couple of times and then give up. It does that not in a very smart way (it retries essentially in a tight loop) which may cause starvation of the process that's holding the file open, especially on slower machines. A solution may be to set a timer and retry after some time has elapsed, as was proposed in https://github.com/npm/npm/issues/12059. Another solution might be to simply keep retrying for a bit longer.
-
The easiest way to test this is to install a separate copy of npm in the user's home dir, patch that up, and invoke this copy (node npm-cli.js) to install APIC.
-
In order to find out what process is interfering, I recomment using Process Monitor (https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx). Make it capture all file system activity (by all processes) while npm runs. After npm stops (fails), stop logging events, and then search list of events for the filename that caused the error (the one that appeared in the error message), and you should be able to see whether/which other processes were interfering.
-
Bert
-
--trace_opt --trace_deopt
will tell you about optimizations
abort on uncaught exception, a flag to do that exists
core files... gdb macros to dump js stack frames and objects?
https://github.com/trevnorris/tracemeur
http://www.joyent.com/blog/walmart-node-js-memory-leak
-
process._rawDebug(msg)
: direct fprintf, doesn't interact with libuv or the event loop, does not support a format string -
node --expose-internals
: allows require('internal/xxx') to access lib/internal/xxx.js
Clean close:
process._getActiveHandles()
process._getActiveRequests()
process._getActiveHandles().forEach(function(handle) {
if (handle.unref) handle.unref()
})
- also, try: https://github.com/thlorenz/active-handles
[2013-06-26 10:45:56 AM] Ben Noordhuis: that's for node handle/req wrap objects
[2013-06-26 10:46:32 AM] Ben Noordhuis: in gdb, you can `call
uv_print_all_handles(0)` and `call uv_print_active_handles(0)`
[2013-06-26 10:47:36 AM] Ben Noordhuis: listing handles that 'become ready' is
not really possible right now, there's not a single list of handles that are
somehow primed
[2013-06-26 10:48:02 AM] Ben Noordhuis: i've considered adding that but the
current approach gives better performance because you can dispatch earlier
[2013-06-26 10:49:20 AM] Ben Noordhuis: btw, the legenda for
uv_print_{all,active}_handles is A=active, R=ref'd, I=internal
(node) warning: Recursive process.nextTick detected. This will break in the next version of node. Please use setImmediate for recursive deferral. RangeError: Maximum call stack size exceeded
The weird thing is, courtesy of grep I'm confident that we do not utilize process.nextTick anywhere; neither in our code nor in any modules we use.
Any advice on figuring this one out?
--trace-gc
: https://github.com/joyent/node/issues/6258
You can start node with --trace-deprecation or --throw-deprecation to see where the warnings come from.
- How to do above from inside mocha? Can be set in env?
https://github.com/iojs/io.js/pull/1077#discussion_r26780492
Forgot to mention, you can get a reasonable approximation of non-idle time by passing -j or --js to the tick processor. That filters out samples that aren't accountable to JS land.
https://gist.github.com/trevnorris/7712539
If you've installed node from nodejs.org installer, how do you get the d8 tick processor? do you have to download src, and build? if you build, won't the
addresses be different, so an existing v8.log won't be processable?
indeed, I'm not seeing it failing now too
octetcloud: npm install -g tick-processor
octetcloud: what indutny said
octetcloud: btw, try #nodejs channel for this ;)
octetcloud: you can build from deps/v8
tick-processor module will fail if running stuff on master
tjfontaine: master is not on nodejs.org
octetcloud: here are some steps: https://gist.github.com/trevnorris/7712539
octetcloud: alternatively you could use dtrace ;)
indutny: thanks, I'll try the npm install, just to see what it looks like for people who don't run from src
octetcloud: once spawnSync makes it into node we can easily shim the environment and make the tick processor run in node with proper symbol resolution, hmm?
what does spawnSync have to do with that?
tjfontaine: the tick processor script calls some d8-specific functions to spawn nm
oh that sort of stuff
Conversation was pretty high level, mostly gave a sense of what kinds of things people are interested in.
Reconstruction of async state:
-
async-listener is considered a good user-facing API
We should have a stance on that. Is it good enough for us? Is it not? Is async-tracker better/worse, why? Can we build zones & strong-agent on top of async-listener? If not, why?
-
async_wrap is considered not good enough for async-listener
Why? What are its issues? If it has them, we should comment on them.
Other:
-
node-inspector will be obsoleted by chrome dev tools...
Hm... why? Only if the blink debug protocol gets ripped out into io.js.
-
interest in exposing whatever v8 has into iojs javascript apis
https://github.com/iojs/io.js/blob/9a8f186/deps/v8/src/counters.h#L294-554
-
interest in getting better static and/or dynamic trace support
Interesting suggestion about having natives in node_javascript.cc include BOTH the dtraceified src, and non-dtrace js, so that iojs can switch between them from the command line. @ben, seems reasonable to me
And comments in https://docs.google.com/a/strongloop.com/document/d/1v2RoPANCZE3oHvY6nPxksAw1RBRNfsdXcGRpWfuUc4Q/edit indicate that the DTRACE probes don't work... really?
https://github.com/thlorenz/cpuprofilify https://github.com/thlorenz/flamegraph https://www.npmjs.com/package/transaction-tracer https://www.npmjs.com/package/async-listener https://github.com/Raynos/leaked-handles https://github.com/thlorenz/traceviewify#screenshots
https://github.com/mafintosh/why-is-node-running
var dump = {
handles: function() {
var fmt = require('util').format;
var inspect = require('util').inspect;
var handles = process._getActiveHandles();
console.log('ActiveHandles:');
handles.forEach(function(h, i) {
console.log('%d: %s', i, pretty(h));
});
function pretty(h) {
if (h === process.stderr)
return fmt('process.stderr/type=%s/fd=%j', h._type, h.fd);
if (h === process.stdout)
return fmt('process.stdout/type=%s/fd=%j', h._type, h.fd);
if (h === process.stdin)
return fmt('process.stdin/type=%s/fd=%j', h._type, h.fd);
if ('_idleNext' in h)
return fmt('timer:msecs=%s:count=%d', h.msecs, timerCount(h));
if ('_connections' in h)
return fmt('server:%j', h.address());
return inspect(h, {depth: 1});
}
function timerCount(h) {
// XXX the circular list always has one extra entry for each setTimeout
// call, why?
var count = -1;
var first = h._idleNext;
var next = first;
while (next) {
next = next._idleNext;
count++;
if (next === first)
break;
}
return count;
}
},
requests: function() {
console.log('ActiveRequests:', process._getActiveRequests());
},
};
dump.handles();
dump.requests();
@fadi could you point to the js api used in chrome to get events? and is it targeted to go in v8, or just the trace_event.h c++ API?
https://codereview.chromium.org/827993003/patch/20001/30008
@sam, in the doc there is another CL for chrome The original doc shared by nduca
https://github.com/johnmccutchan/adb_trace
https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/edit
https://codereview.chromium.org/707273005/
@fadi: in above I don't see any api, wherein in javascript, you can recover the trace events that have been added fair enough, so it could be first consumer to register wins
https://github.com/chrisa/node-dtrace-provider/blob/master/dtrace_provider.cc#L116
trace_event.h
event_tracing.cc
what version of v8 is a stable version of the trace_event system targeted for? not sure at the moment
https://github.com/iojs/io.js/issues/877
https://docs.google.com/a/strongloop.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU
https://codereview.chromium.org/827993003
https://github.com/iojs/io.js/issues/671#issuecomment-74737098
https://docs.google.com/a/strongloop.com/document/d/1_ApOMt03xHVkaGpTEPMDIrtkjXOzg3Hh4ZcyfhvMHx4