Enable diagnostics in release #1263
Conversation
Rob-Hague
force-pushed
the
diagnostics
branch
from
cf4026a
to
d2fb3ac
Compare
There was a problem hiding this comment.
What rationele did you apply for deciding when to "protect" logging with a corresponding IsEnabled(...) check?
I see you protecting (cheap) warning-level logging, but not verbose-level logging. While you could expect more people to have warning and error level logging enabled by default, but almost no one enables verbose logging unless you're troubleshooting an issue.
Can you perform (and commit) a (a simple connect) benchmark that shows the impact on performance with all tracing disabled (with any without this PR applied)?
I don't think we have benchmarks where we make use of our docker infrastructure.
Would be nice to have this. @WojciechNagorski, am I right?
That said, I'd love to get this PR in! Thanks!
If the message is a literal string, I did not guard it.
I don't think a benchmark would be suited for such an end-to-end networking scenario (too much noise). The module shows as ~1% of CPU of a basic connect->listdirectory->downloadfiles scenario at verbose level, and does not show in a memory trace.
Where we could use the benchmarks project is to define a number of scenarios from which it is easy to generate profiles for identifying where we should place the focus on performance. I found a nice blog which could be used as a reference 😉 |
src/Renci.SshNet/Channels/Channel.cs
Outdated
| @@ -554,9 +554,9 @@ protected virtual void Close() | |||
| // SSH_MSG_CHANNEL_CLOSE as response to a SSH_MSG_CHANNEL_CLOSE sent by the | |||
| // server | |||
| var closeWaitResult = _session.TryWait(_channelClosedWaitHandle, ConnectionInfo.ChannelCloseTimeout); | |||
| if (closeWaitResult != WaitResult.Success) | |||
| if (closeWaitResult != WaitResult.Success && Diagnostics.IsEnabled(TraceEventType.Warning)) | |||
There was a problem hiding this comment.
I don't get why we need the condition Diagnostics.IsEnabled(TraceEventType.Warning) outside the log method.
what if someone forgot to check it?
There was a problem hiding this comment.
We don't need it, it just prevents doing any extra work like allocating string instances unnecessarily in the case that the log level is not enabled. But TBH I don't think it would make a material impact either way.
This should make troubleshooting apps easier