Skip to content

Latest commit

 

History

History
286 lines (215 loc) · 10.1 KB

2015-02-05.md

File metadata and controls

286 lines (215 loc) · 10.1 KB

February 5th 2015

Event

YouTube

Agenda

  • async_wrap
    • what can we do now?
      • Trevor is documenting what is available now.
    • what more do we want to see
      • Proper support for timers, continuations of nextTick and interception of errors.
      • Provider filters (only call the callbacks for specific types. e.g. TCP).
      • Work with V8 to make it so callbacks sent to the Microtask processor can be intercepted in a useful way.
  • async-listener
    • Will live in userland so it can be iterated on more quickly as the API is hashed out. Forrest is the initial point of contact, but would like more shareholders to be invested in the library.
    • Complete implementation requires completing several items on the async_wrap roadmap.
  • tracing
  • what does the current tracing work look like and how can it be improved
    • What external tools can be used?
    • What can be analysed at runtime w/o any external tools?
    • Is the data for in-depth profiling output, or for long-term real-time data?
  • is generic tracing possible
    • Does the tracing require an external tool (e.g. dtrace) or not?
  • Tracing documentation.
  • Thorsten has done work with dtrace/perf and getting unified output. There are some caveats (e.g. have to kill the proc to stop generating the perf.map file) but shows promise to unify external tracing output.
  • v8 tools

    • node-inspector

    • will be obviated by work Google is doing to pull out Chrome's tools and connect them to iojs using blink.

    • flame graphs

    • @thlorenz is working on flame graphs without tracing (pure v8)

    • Usage of additional V8 APIs that allow introspection.

  • libuv
  • what metrics are people interested in?
  • libuv is extremely easy to hook into using external tools. Also it’s not uncommon that calls to libuv are masked by the JS API for simplicity. So users wouldn’t exactly know what to look for. For this case it would be easier to just expose an io.js API to get relevant information.
  • io.js WG charter
  • @mikeal will write it up and send a PR.
  • update on Linux tracing
  • Request for tracing API ticket
  • Suggested that we split work between system tools integrations (trace from the outside) and tracing from the inside (pure node tools).

Attendance

  • Forrest L Norvell (async-listener, continuation-local-storage, node-newrelic) [email protected]
  • Mikeal Rogers
  • Trevor Norris (wrote async_wrap) [email protected]
  • Glen Keane (lttng linux tracing) [email protected]
  • Krishna Raman
  • Michael Hayes (making native Promises work w/ async listener)
  • Stephen Belanger
  • Ali Ijaz Sheikh (ofrobots@google. Debug/Trace for node at Google)
  • Ryan
  • Sam
  • Thorsten Lorenz

Meeting notes

stand-up:

  • Ali (Google): working on tooling and debugging for io.js and Node
  • Forrest (npmjs.com): revising async-listener & continuation-local-storage
  • Glen (nearForm): lttng, getting up to speed with tracing in core
  • Krishna (StrongLoop): working on Zones, separate project called async-tracker that puts a generator API around it
  • Michael Hayes (New Relic): native promises in async-listener, more stuff for New Relic
  • Ryan (StrongLoop): code reviews relevant to async tracing, Node in production
  • Sam (StrongLoop): NodeOps, strong-agent -- extracts profiling and tracing information from processes, worked on Zones
  • Stephen (AppNeta): instrumentation for AppNeta, digging into nodejs / io.js core to find new source of trace information (DTrace, lttng -- is there a generic API to expose that userland can build upon?)
  • Trevor (NodeSource): async_wrap author
  • Thorsten (NodeSource): looking at existing tracing tools and figuring out how to use them, adapting tools to dump something that can create flamegraphs and dump perf metrics to Chrome tracing tools, generate full backtraces using existing external tracing tools

Trevor's async_wrap infodump

  • will post initial documentation EOD
  • left it undocumented to leave freedom to change API
  • what's left to do?
    • proper support for timers
      • for perf reasons, timers are implemented as a linked list
      • so nothing is notified on the native side on its own
      • requires hooks
    • process.nextTick should be transparent, so state is propagated
    • error listener - allow capturing with original stack if nothing else has gotten to
  • no way to intercept callbacks that are sent to the V8 microtask queue
  • technically calls to native Promises are asynchronouse, but not interceptable
    • needs V8 team involvement before native promises can be supported within async_wrap
  • providers to filter async_wrap requests by "provider" -- modeled on DTrace providers

Stephen: main thing needed is to be able to link stuff together, which is basically there

Trevor, Forrest: there are other requirements that aren't quite there

Forrest: gotta make sure AppNeta and New Relic have the features necessary without overhead

hayes: need more context than is available with the async-listener API

trevnorris: much of that is already in async_wrap, but not documented

?: how is that run?

Trevor: before and after async events

othiym23: I don't want to be the gatekeeper on async-listener, necessarily

mikeal: the more this can be done without requiring Trevor, the better

  • Domenic Denicola can handle this stuff on the V8 side
  • the rest of the stakeholders can iterate on this in userland

Trevor: I really want to not be the single point of failure here; want to work with those hardy enough to dive deep

Tracing in general

Mikeal: let's talk about tracing and interaction with other tracing

Trevor: do you want counters, or stacktraces?

  • async_wrap can give you counters, not profiles

Glen: tracing hooks for linux are more profiler-based

  • would like to be able to capture full stacktraces using a generic library that DTrace and all the other dynamic tracers can hook into

Mikeal: Glen, your current PR is a bunch of patches, what level does it come in at?

  • parallel with DTrace

Thorsten:

  • not sure special dynamic tracing support is needed
  • current approach with DTrace gets resolvable dumps from both C++ and JS
  • DTrace and perf will get all the performance metrics at 1ms resolution, which is good enough
  • tooling needs to be simpler and more approachable, but it may not need to be in core

Mikeal: but Linux

Thorsten: there are modules that smooth over the differences between DTrace and Perf

Glen & Thorsten will hook up to discuss also making that work with lttng

{Thorsten standup}

Stephen: one-off debugging tools are great, but APM products that need realtime metrics need something more realtime

Trevor: are you talking more about things that can be reached from a JavaScript API? or more something that creates a low-level API within the C++ level that allows devs to swap in multiple dynamic / static tracing low-level APIs

Stephen: more native

Trevor: not nec. going to Node, but exposes control hooks (start / stop listening, attach listening to files / sockets) to JS

Thorsten: assuming we have all this other stuff, why do we need static probes?

Forrest:

  • deployment needs to be simple - Heroku
  • this is why APM wants the interface to be exposed entirely within process

Thorsten: but external tools and internal tracing are two problems

Forrest: yeah, but [last January]

modern V8

Thorsten:

  • latest V8 added new hooks to get information about JITted code
  • emits a code creation event
  • perf --basic-prof can get access to that information
  • otherwise need to walk the heap to deserialize code and arguments
  • uses gdbjit symbols that are generated to display stacktraces
  • OS X is problematic, not sure why
  • Mach-O stuff gets generated at runtime and the debugger (lldb?) hooks into it at runtime, but for whatever reason it's not quite working
  • motivation for his intermediate tooling

Ali:

  • starting to look at how to get more developer tools available

Mikeal: what's the state of node-inspector?

crickets

Mikeal: will talk to that team

Thorsten:

  • node-inspector uses the debug port entirely, but not the Blink protocol
  • Google has the Chrome team dedicated to ripping all that stuff out

Mikeal: so node-inspector will be deprecated at that point?

Thorsten: should think so

Trevor: https://gist.github.com/trevnorris/2d4036f54b1b2714ca1e

Trevor: better to get the information out of V8, no?

Thorsten: Trevor is working on introspecting the V8 JIT as it runs

Stephen:

  • that's my ultimate goal
  • doesn't need the low-level detail from DTrace, just the events that are of interest from Node / io.js

libuv

mikeal: are there any metrics exposed from libuv we could be capturing?

Trevor: a lot of the libuv events are irrelevant to end users, they just want to know the end effects

other topics

Thorsten:

  • at least two major efforts, should split up (that never works out well in Scooby Doo)
    1. tracing from the outside
    2. APM
  • does it make sense to split up?

Forrest: one group, two streams of work

Mikeal: agreed

next steps

Mikeal will make the WG charter happen because he is ON IT.

Glen is working on merging in the lttng PR, but wants it to be more generic wrt the hooks from the JavaScript level.

Thorsten:

  • all the core modules are bundled with node in a string in a C++ file.
  • what about having multiple versions of the probes by choosing two different dumps at compile time (and then having multiple binaries)

Stephen:

  • macros chosen at build time that feeds data to an external module on perf events of given classes.
  • If they're turned off, no events to go to this external module.

Trevor really wants strawman code samples of what APIs people want to work idea. Get them to Trevor using [a flock of birds]

Trevor will create a tracking issue on which everyone can put their gists.

  • Stephen will try to give Trevor a gist

Glen is trying to make it easier for people to write their own instrumentation.

Forrest will look at the docs and come up with a way to use async_wrap in async-listener.

Glen wants to get his PR merged.