-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Socket's connect operations tracing #38620
Conversation
Tagging subscribers to this area: @dotnet/ncl |
/azp run runtime-libraries outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketsTelemetry.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketsTelemetry.cs
Outdated
Show resolved
Hide resolved
namespace System.Net.Sockets | ||
{ | ||
[EventSource(Name = "System.Net.Sockets")] | ||
internal sealed class SocketsTelemetry : EventSource |
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.
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.
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.
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.
@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?
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.
Issue already exists, but it's outside .NET 5.0 scope.
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.
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.
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.
(and if we really want to use that same issue, the description and the milestone should be updated)
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 created a dedicated issue #38754 for this, but it needs to be triaged to see if it can fit in .NET 5.0 scope.
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.
Thanks
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 added some thoughts to #38754 and may have more once I get a chance to look into this more
src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEventArgs.cs
Outdated
Show resolved
Hide resolved
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 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.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketsTelemetry.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketsTelemetry.cs
Outdated
Show resolved
Hide resolved
- ConnectFailed always calls ConnectStop - Redundant Write method removed
/azp run runtime-libraries outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketsTelemetry.cs
Show resolved
Hide resolved
FYI. There is a typo in the last commit name. It's intended to be ConnectStopInternal. |
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketsTelemetry.cs
Show resolved
Hide resolved
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketsTelemetry.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEventArgs.cs
Outdated
Show resolved
Hide resolved
- ConnectCanceled logs Stop
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 made a few suggestions inline but the high order bit is probably to resolve whether a new EventSource should exist at all in #38754.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEventArgs.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEventArgs.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketsTelemetry.cs
Outdated
Show resolved
Hide resolved
…s://github.com/alnikola/runtime into alnikola/827-log-timings-in-socketshttphandler
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketsTelemetry.cs
Show resolved
Hide resolved
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketsTelemetry.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs
Outdated
Show resolved
Hide resolved
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); |
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.
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 : )
- Functional tests
…led are logged via public non-event methods
/azp run runtime-libraries outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
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
Socket's connect start, stop and cancelled events are logged as activities via EventSource.
Contributes to #37428