-
Notifications
You must be signed in to change notification settings - Fork 30.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
perf_hooks: add ReqWrap latency monitoring #26556
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Heh. Looks like ci was a bust ;) will review those today |
Is the omission of |
Yes, there is no resolution because this monitor is not timer or sampling based. Once enabled, it's on for all ReqWrap instances |
861145a
to
d51cdb3
Compare
I think it would be nice to include the number of measurements done into the resulting histogram. |
if (*TRACE_EVENT_API_GET_CATEGORY_GROUP_ENABLED( | ||
TRACING_CATEGORY_NODE2(perf, reqwrap)) != 0) { | ||
auto value = tracing::TracedValue::Create(); | ||
DumpToTracedValue(value.get()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel that it is an overkill to trace the whole Histogram on every call to Record
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can tweak this later if necessary. How often would be acceptable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually I would expect that traces act on raw data therefore trace type
and delta
on every call of Record
.
I would not expect a trace holding the whole histogram in the same category as it is redundant information.
But as you said on summit the requirements what should be traced are missing in general so feel free to keep this as it is and adapt once there is a more clear picture in this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could tweak this a bit to be sensitive to detail level... e.g. output type and delta for category node.perf.reqwrap
and the full histogram on node.perf.reqwrap.detail
or something similar, but for now, I'd like to leave it as is.
@jasnell Thanks! I like this solution. The only drawback I see in adding filters is that the names of the async providers get to the public API surface even they are more an implementation detail. This is also the case in async_hooks and caused some discussions there in the past. |
The only other way I could think of doing this would be to group by types of activity e.g. |
Adds a histogram that tracks ReqWrap latency (defined as the length of time it takes from when the reqwrap is dispatched to when the callback is invoked)
cf7937a
to
f4d1802
Compare
CI is good. |
inline void Histogram::GetMin( | ||
Histogram* histogram, | ||
const FunctionCallbackInfo<Value>& args) { | ||
double value = static_cast<double>(histogram->Min()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Min()
returns int_max which results in min: 9223372036854776000
if no measurement was done (e.g. after reset()
) which looks not that nice. Maybe set min/max
to NAN
in case count
is 0?
This needs a rebase. |
Yep, I'll be getting back to this next week. |
Sigh... looks like it took longer than a week to get back to this ;-) ... will be updating it soon |
Should this remain open? |
Yes, please keep it open
…On Sun, Nov 3, 2019, 15:19 F. Hinkelmann ***@***.***> wrote:
Should this remain open?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#26556?email_source=notifications&email_token=AADLM6NGVZNPNSJGT2OZ6WLQR5E7DA5CNFSM4G44AP52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC57SZY#issuecomment-549189991>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADLM6LSPBKSKRL5RJFG3FDQR5E7DANCNFSM4G44AP5Q>
.
|
Ping @jasnell |
Took a quick pass at rebasing this but it seems to conflict with #29317, which makes ELDHistogram a HandleWrap now. I'm not sure how to resolve that without undoing that change as HistogramBase and RWLHistogram don't have the timer and therefore don't make sense as HandleWraps. However, HistogramBase extends from BaseObject, which means the ELDHistogram subclass couldn't independently extend from HandleWrap without introducing a diamond-of-death problem. 🤔 |
I'll be picking this back up in the next couple of weeks. |
Going to go ahead and close this. I want to return to this but do not have time at present |
Similar to the recently added event loop relay, this adds a
perf_hooks.monitorRequestWrapLatency()
API that tracks the length of time between dispatching a ReqWrap and when the callback is invoked. This effectively tracks how long libuv is taking to perform requested actions. No differentiation is made between types of actions. The idea here is to provide a pulse on the general health of the application. If the histogram skews high, then it's taking libuv a longer time to process individual requests.Also outputs histogram data to the trace event log.
/cc @mcollina @mafintosh @nodejs/diagnostics
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes