"cpu time" vs "request time"

[evantahler]

I'm curious if there is a way to instrument a request which will report on both the "real request time" (time between request and response) vs (CPU time per request).

NewRelic is clear to say by percent of wall clock time, which means "request time", but it would be useful to be able to generically see the "load" each request takes.

[evantahler]

This could be tested with

var http = require('http');
http.createServer(function (req, res) {
  setTimeout(function(){
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('Hello World\n');
  }, 5000)
}).listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');

"real time" would always be 5s, and cpu time would be something like 10ms for each request

[othiym23]

There's a couple obstacles to doing this in a way that's not misleading:

1. We'd need to be tracking the execution time for every function and callback that's part of a given asynchronous invocation, e.g. if you were reading a result set from MySQL or Mongo, you'd need a timing for each individual callback invocation as an object is fetched from the cursor. To cut a long and very inside-baseball conversation short, this could be done, but it's not how it's done right now.
2. Node would need to provide an accurate CPU time call. It sort of blew my mind when I learned there's nothing in Node analogous to Python's os.times() or Ruby's Process.times (I would say it's because it's hard to do in a cross-platform way (read: for Windows), but Python managed it, so it's probably just a matter of nobody ever having gotten around to it), but it's true. Because of deployment considerations, New Relic can't depend on any binary modules, and we do support Azure Web Servers, so adding our own support for this isn't as simple as just calling fs.readFileSync('/proc/self/stat') and parsing the output.

It is an ongoing project of ours to improve New Relic for Node's reporting of parent-time vs child-time function execution in transaction traces (which will bring with it improvements to the transaction breakdown charts), which is where getting better at the first item on the list above will yield significant benefits, but due to how all the data is represented (and the representation's inbuilt assumptions that the timings are being generated from synchronous processes), it's a little harder than it looks.

Good idea, though! Thanks!

[evantahler]

Thanks for all the information! Good luck!

[txase]

There is nothing actionable for the Node.js agent at this point, so I'm closing this issue. Thanks for the feedback on a requested feature!