-
Notifications
You must be signed in to change notification settings - Fork 10.6k
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
Add tracer for handshakers. #15090
Add tracer for handshakers. #15090
Conversation
|
#include "src/core/lib/iomgr/timer.h" | ||
|
||
grpc_core::TraceFlag grpc_handshaker_trace(false, "handshaker"); |
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'm guessing the DebugOnlyTraceFlag will not work?
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'm sure it would work, but I don't know why it would be necessary. In general, DebugOnlyTraceFlag is for cases where enabling the tracer imposes a large amount of overhead that we don't want in opt builds (e.g., things like ref-count tracing, which occurs a lot). That's not the case here, so there's no reason not to allow this tracer even in opt builds.
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 agree that the overhead would not be much but I would prefer to not add unnecessary overhead.
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.
By that logic, why would we support any tracer in opt mode? I don't understand why this particular tracer would be different than any other.
Note that there is no additional overhead unless the tracer is actually enabled.
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.
Mark, is there a specific reason to want this tracer in opt builds ? We have seen a general downward drift in performance benchmarks, so I would lean towards avoiding this overhead unless there is a specific need.
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.
As per our discussion, it is very useful to support tracers in opt mode, because this allows customers to enable them without pushing a debug binary (which they often can't for performance reasons). This makes it easier to gather useful debugging information when a customer runs into a problem.
If we're really worried about the branch-prediction performance impact of a few if
statements checking whether the tracer is enabled, I would suggest that we find a structural way to make use of the GPR_UNLIKELY
macro that @yashykt recently added in #15009. For example, perhaps we could use that in the TraceFlag::enabled()
method.
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.
Based on offline discussion, we will explore adding compiler hints to the tracers to avoid perf impact.
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 if the DebugOnlyTraceFlag will not be enough
|
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.
Looks good overall.
@AspirinSJL, I need an owners approval for this. Thanks! |
|
|
This adds some logging needed to debug a handshaker problem being reported internally.
Note that this will require adding the name field to the handshaker vtables in internal code before we import this. Once this PR is ready to merge, I'll prepare the necessary internal change.