Tracing use cases and interface #31

Activity

1. bnoordhuis commented on Oct 9, 2015

   

   bnoordhuis

   on Oct 9, 2015

   Member

   More actions

   I think a good first step would be to make sure that the tracing infrastructure can do what the dtrace/etw/lttng/systemtap USDT probes do now. There are only a handful of them so that shouldn't be a huge undertaking. For posterity:

   lib/_http_client.js:163:  DTRACE_HTTP_CLIENT_REQUEST(this, this.connection);
   lib/_http_client.js:410:  DTRACE_HTTP_CLIENT_RESPONSE(socket, req);
   lib/_http_server.js:100:  DTRACE_HTTP_SERVER_RESPONSE(this.connection);
   lib/_http_server.js:473:    DTRACE_HTTP_SERVER_REQUEST(req, socket);
   lib/net.js:402:  DTRACE_NET_STREAM_END(this);
   lib/net.js:1424:  DTRACE_NET_SERVER_CONNECTION(socket);
   

   (The DTRACE_ prefix is for historical reasons, we should rename them.)

   Once that works, we can think about adding trace points to e.g. the ArrayBuffer allocator, the various Wrap constructors/destructors, and so on.

   Sounds reasonable? Who's volunteering?
2. trevnorris commented on Oct 12, 2015

   

   trevnorris

   on Oct 12, 2015

   More actions

   I'm fine to implement that, but what would the API be? The hooks I'm thinking of would live in the native code, not in JS.

   Additionally I think it's a poor JS API decision to simply call the function and say "it's a noop". Because in reality it isn't. These should be conditionally wrapped, regardless of how ugly it looks. Especially if they're going to be injected into more and more locations in the future.
3. bripkens commented on Jan 3, 2016

   

   bripkens

   on Jan 3, 2016

   More actions

   @lucamaraschi: […] we should define some concrete use cases […]

   From nodejs/node#4496:

   As a developer, I want to see when garbage collections happen and
   how long they take in the production environment so that I can get a
   feeling for GC pressure and the behavior of my application.
   

   @trevnorris: The hooks I'm thinking of would live in the native code, not in JS.

   Assuming that you define hooks as "an API to access trace data": It would be neat to see a JS API for that. Main reason as outlined in nodejs/node#4496:

   Users of such monitoring tools, or more generally users interested in GC activity, need to compile native addons in order to access this information. It is hard to explain why users need to do this (or have a package such as build-essential installed). This gets increasingly harder in Java shops which are used to having everything in the platform. Building these addons automatically on install only reduces this problem, but doesn't remove it.

   Being able to retrieve this information from JS directly would mean that monitoring tools could ship with fewer addons.
4. trevnorris commented on Jan 4, 2016

   

   trevnorris

   on Jan 4, 2016

   More actions

   I didn't mean there wouldn't be a JS API, only that the hooks/counters would exist in the native side.
5. joshgav commented on Sep 21, 2016

   

   joshgav

   on Sep 21, 2016

   Contributor

   More actions

   closing old AsyncWrap issues, please start a new thread if appropriate

   The API and format discussion is continuing in #53
6. joshgav

   closed this as completedon Sep 21, 2016