Skip to content
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

Socket's connect operations tracing #38620

Merged

Conversation

alnikola
Copy link
Contributor

Socket's connect start, stop and cancelled events are logged as activities via EventSource.

Contributes to #37428

@alnikola alnikola added this to the 5.0.0 milestone Jun 30, 2020
@alnikola alnikola requested a review from a team June 30, 2020 14:42
@ghost
Copy link

ghost commented Jun 30, 2020

Tagging subscribers to this area: @dotnet/ncl
Notify danmosemsft if you want to be subscribed.

@alnikola
Copy link
Contributor Author

/azp run runtime-libraries outerloop

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

namespace System.Net.Sockets
{
[EventSource(Name = "System.Net.Sockets")]
internal sealed class SocketsTelemetry : EventSource
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We now have two EventSources in this library. Is that really what we want? I'm not clear on why the decision was made to add a new one. I really don't want to be in a position of having to carry both forward indefinitely.
cc: @noahfalk, @brianrob, @davidsh

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally, you have one EventSource per area of functionality. There's no hard and fast rule, but unless there's a reason to have multiple EventSources I'd recommend just having one. It also makes it easier to consume the events.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alnikola, this doesn't need to block your PR, but I do want us to resolve this for .NET 5. Can you please make sure there's an issue for it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Issue already exists, but it's outside .NET 5.0 scope.

Copy link
Member

@stephentoub stephentoub Jul 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is related but different. These PRs are actively doubling the number of event sources used. How is a customer supposed to reason about that: they want socket events, but they need to enable two different providers depending on the events they want? There's no good reason for it. If we're doing a new one because we don't like the old one, we should remove the old one. If we're fine with the old one, we shouldn't introduce the new class. Adding new types like this adds overhead, adds confusion, and adds legacy code to be maintained.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(and if we really want to use that same issue, the description and the milestone should be updated)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I created a dedicated issue #38754 for this, but it needs to be triaged to see if it can fit in .NET 5.0 scope.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added some thoughts to #38754 and may have more once I get a chance to look into this more

Copy link
Contributor

@scalablecory scalablecory left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have an established pattern for logging elsewhere of checking Enabled before calling the logging method, rather than checking it inside the method.

I prefer this new pattern's readability, but it looks like in some cases it will add some extra overhead when tracing is disabled. These are logged on a relatively expensive connect operation so overhead here will get swallowed, but still pointing out in case we use this pattern in less expensive areas.

@alnikola
Copy link
Contributor Author

alnikola commented Jul 1, 2020

/azp run runtime-libraries outerloop

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@alnikola
Copy link
Contributor Author

alnikola commented Jul 3, 2020

FYI. There is a typo in the last commit name. It's intended to be ConnectStopInternal.

- ConnectCanceled logs Stop
Copy link
Member

@noahfalk noahfalk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made a few suggestions inline but the high order bit is probably to resolve whether a new EventSource should exist at all in #38754.

@noahfalk
Copy link
Member

I prefer this new pattern's readability, but it looks like in some cases it will add some extra overhead when tracing is disabled

Assuming the if check is at the top of the EventSource method and you do no argument transformation beforehand the overhead should be call-setup/return. This varies based on arguments and machine, but I usually consider it in the 1ns order of magnitude. If performance on that scale matters for a given scenario then certainly we should benchmark and go from there.

@@ -2071,6 +2072,8 @@ private bool CanUseConnectEx(EndPoint remoteEP)

internal IAsyncResult UnsafeBeginConnect(EndPoint remoteEP, AsyncCallback? callback, object? state, bool flowContext = false)
{
if (SocketsTelemetry.Log.IsEnabled()) SocketsTelemetry.Log.ConnectStart(remoteEP);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Style-wise I've always found it preferable to eliminate these IsEnabled() calls entirely and rely on the checks that occur inside the EventSource, but I think the mono-linker will fully remove this pattern so its purely style and tiny perf at this point. Style is best decided by the folks who have to work on the code rather than me : )

@alnikola
Copy link
Contributor Author

/azp run runtime-libraries outerloop

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Copy link
Member

@ManickaP ManickaP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@alnikola alnikola merged commit a84538d into dotnet:master Jul 14, 2020
@alnikola alnikola deleted the alnikola/827-log-timings-in-socketshttphandler branch July 14, 2020 14:18
@ghost ghost locked as resolved and limited conversation to collaborators Dec 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants