v0.8.0 #430
v0.8.0 #430
Conversation
* add automatic log correlation of tracer identifiers for pino * add missing plugins to the build
* Add protocol as a configuration option for the dd-trace agent URL. This is useful for scenarios where a SSL-terminating load balancer sits in front of the datadog-agent * Fix lint errors * Switching from protocol override to url override per CR * Fixing missing comma from previous commit * Fix tests * overrideUrl -> url
| } else { | ||
| ScopeManager = require('./scope/scope_manager') | ||
| ScopeManager = require('../scope/scope_manager') |
There was a problem hiding this comment.
Hi @rochdev, I'm curious about this line. Why do we need the real scope manager for the noop tracer? We're checking the performance with the tracer on and off, but I suspect the async hooks code is still on even with enable=false on the tracer...
There was a problem hiding this comment.
Yes, this was because we considered it a cross-cutting concern that can still be enabled if the tracer is disabled. In the upcoming 0.9.0 version the scope manager was rewritten from scratch and is no longer enabled when the tracer is disabled.
It's possible to still disable it in 0.8.0 by using DD_CONTEXT_PROPAGATION=false but it can have unwanted side effects if you use our integrations since they expect the scope manager to be available.
There was a problem hiding this comment.
In general an overhead of around 20% can be expected from the async_hooks module which should hopefully improve with new versions of Node and v8.
There was a problem hiding this comment.
Got it. Do you think the new version of the scope manager, independent of Node and v8, will have a performance impact? I seem to remember that it was less heavyweight...
There was a problem hiding this comment.
It will definitely help. The current scope manager keeps track of the entire context, along with every parent/children to try to know when all descendants have finished execution, which ended up significantly increasing the complexity with basically no gain.
The new scope manager is very simple in nature and does nothing other than storing/retrieving spans in an object-based map. Any remaining overhead would generally be caused from the interaction between async_hooks and Promise which is very slow.
The only way I know at the moment to mitigate this issue is to either use a Promise library instead of native promises, which should be several orders of magnitude faster (even without async_hooks). I'm also experimenting with a solution that is not based on async_hooks which could help in the future but it wouldn't support async/await as it's a native construct, so that would need to be transpiled.
No description provided.