Skip to content

Trim more Http DiagnosticsHandler code #39525

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

Merged
merged 1 commit into from
Jul 21, 2020

Conversation

eerhardt
Copy link
Member

@eerhardt eerhardt commented Jul 17, 2020

Since the DiagnosticsHandler still gets instantiated in the HttpClientHandler, none of its overriden methods are getting trimmed. This leads to System.Diagnostics.DiagnosticListener still being preserved in a linked application.

This fix is split DiagnosticsHandler.IsEnabled() into two methods:

  • IsGloballyEnabled() - checks the AppContext switch, and is replaced by the linker by a feature swtich.
  • IsEnabled() - which checks IsGloballyEnabled() and if there is an Activity or listener available.

This allows all but the IsEnabled and IsGloballyEnabled methods to get trimmed on DiagnosticsHandler.

Contributes to #38765

This allows for ~20KB savings in the default Blazor WASM template app:

Build Size
master 2,420,736 bytes
PR 2,400,768 bytes

@eerhardt eerhardt requested review from marek-safar and ManickaP July 17, 2020 16:46
@Dotnet-GitSync-Bot
Copy link
Collaborator

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

@ghost
Copy link

ghost commented Jul 17, 2020

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

@eerhardt eerhardt requested a review from a team July 17, 2020 16:46
@marek-safar
Copy link
Contributor

marek-safar commented Jul 17, 2020

I like 4c690ff better as the prefered outcome is to have no trace of DiagnosticsHandler in the binary

@ManickaP
Copy link
Member

Question about 4c690ff: it creates the DiagnosticsHandler only if it's enabled and than lives with this decision for the rest of HttpClientHandler live. And we recommend keeping HttpClient around and share it for multiple requests. So, if someone subscribes to the diagnostics after the HttpClient has been created, will they ever receive any events?

@eerhardt
Copy link
Member Author

So, if someone subscribes to the diagnostics after the HttpClient has been created, will they ever receive any events?

I don't believe so. That's the behavior change that I mentioned in the above summary:

However, I was concerned that could affect non-trimmed behavior by moving the DiagnosticsHandler.IsEnabled() check into the constructor of HttpClient, and not during Send.

If we still wanted to take that approach, I believe we can address this by splitting DiagnosticsHandler.IsEnabled() into 2 different methods:

internal static bool IsEnabled()
{
// check if there is a parent Activity (and propagation is not suppressed)
// or if someone listens to HttpHandlerDiagnosticListener
return Settings.s_activityPropagationEnabled && (Activity.Current != null || Settings.s_diagnosticListener.IsEnabled());
}

  1. One that just returns the first part: Settings.s_activityPropagationEnabled. This would be called from the constructor, and can never change for the lifetime of a process (since it is a static readonly bool).
  2. The second method would return the second part of that check: (Activity.Current != null || Settings.s_diagnosticListener.IsEnabled()). This can be called inside Send and SendAsync to check whether it should call _diagnosticsHandler or not.

Thoughts?

@ManickaP
Copy link
Member

I believe we can address this by splitting DiagnosticsHandler.IsEnabled() into 2 different methods

I like it! It addresses the problem while it keeps the original behavior. 👍

Since the DiagnosticsHandler still gets instantiated in the HttpClientHandler, none of its overriden methods are getting trimmed. This leads to System.Diagnostics.DiagnosticListener still being preserved in a linked application.

This fix is split DiagnosticsHandler.IsEnabled() into two methods:

* IsGloballyEnabled() - checks the AppContext switch, and is replaced by the linker by a feature swtich.
* IsEnabled() - which checks IsGloballyEnabled() and if there is an Activity or listener available.

This allows all but the IsEnabled and IsGloballyEnabled methods to get trimmed on DiagnosticsHandler.

Contributes to dotnet#38765
@eerhardt eerhardt force-pushed the TrimHttpDiagnostics branch from 67a3fa2 to 9b09ad7 Compare July 20, 2020 21:52
@eerhardt
Copy link
Member Author

@ManickaP - I've updated the PR to use the above proposal. Let me know what you think.

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, thanks.

@eerhardt eerhardt merged commit 632cdca into dotnet:master Jul 21, 2020
@eerhardt eerhardt deleted the TrimHttpDiagnostics branch July 21, 2020 13:59
Jacksondr5 pushed a commit to Jacksondr5/runtime that referenced this pull request Aug 10, 2020
Since the DiagnosticsHandler still gets instantiated in the HttpClientHandler, none of its overriden methods are getting trimmed. This leads to System.Diagnostics.DiagnosticListener still being preserved in a linked application.

The fix is to split DiagnosticsHandler.IsEnabled() into two methods:

* IsGloballyEnabled() - checks the AppContext switch, and is replaced by the linker by a feature swtich.
* IsEnabled() - which checks IsGloballyEnabled() and if there is an Activity or listener available.

This allows all but the IsEnabled and IsGloballyEnabled methods to get trimmed on DiagnosticsHandler.

Contributes to dotnet#38765
@karelz karelz added this to the 5.0.0 milestone Aug 18, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 8, 2020
@dotnet-policy-service dotnet-policy-service bot added the in-pr There is an active PR which will close this issue when it is merged label Aug 8, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Net.Http in-pr There is an active PR which will close this issue when it is merged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants