- 
                Notifications
    You must be signed in to change notification settings 
- Fork 150
          Stop using Tracer.Instance if we don't need to
          #7744
        
          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
base: andrew/settings/5-remove-mutablesettings
Are you sure you want to change the base?
  
    Stop using Tracer.Instance if we don't need to
  
  #7744
              Conversation
| CommandType = typeof(TCommand); | ||
|  | ||
| if (TryGetIntegrationDetails(CommandType.FullName, out var integrationId, out var dbTypeName)) | ||
| if (TryGetIntegrationDetails(Tracer.Instance.Settings.DisabledAdoNetCommandTypes, CommandType.FullName, out var integrationId, out var dbTypeName)) | 
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.
This one is actually kind of annoying. As it's in a static cctor, we can't pass it in anywhere, which means there's one DbScopeFactoryTests test which will use this and end up initializing the global tracer. Oh well.
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.
:sorry: pretty sure this was me
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.
Hmm. I understand that we want to minimize work but I feel like we should calculate all DbCommands regardless of config (i.e. no dependency here) and then we do the config check on the hot path, which allows this setting to be hot-reloadable or "config at runtime" ready
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.
Concretely, I'm suggesting that we remove the TryGetIntegrationDetails call in the static constructor of Cache<TCommand> and refactor the other call in CreateDbCommandScope a bit. Perhaps in a separate PR
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 can see arguments both ways tbh.
The only downside to @zacharycmontoya's  proposal would be more work to do for custom DbCommands (ones that we don't explicitly know about), which are also marked as disabled initially, and which customers have marked as disabled. The question I would have is whether that's ok - e.g. if they're disabled because we're erroring out literally running TryGetIntegrationDetails, and that's why they disabled it, then that could be a problem. If it's just an optimization, then yes, it probably is fine.
That said, this actually is technically already hot-reloadable. The DisabledAdoNetCommandTypes setting passed in here is used to decide whether to populate the cache for custom types, but if we don't populate the cache, then we run TryGetIntegrationDetails() and check DisabledAdoNetCommandTypes at runtime anyway. So if this changes, then the result changes, it will just never be cached in that scenario.
So on that basis, I think removing the TryGetIntegrationDetails has a small amount of risk (if customer disabled adonet due to errors - not sure if that's really possible, but I can believe it), means a small bit more work (calculating values which will never be used), and doesn't change how hot-reloadable we are in general (though if we made it hot reloadable, we'd have to rethink how caching works). The plus side is it removes the static access to Tracer.Instance which is better for tests.
So yeah, I'm torn 🤷♂️ I'd say separate PR either way, given the questions, as the current behaviour in this PR is identical to the existing. But it's worth thinking about
| 
 | 
| CommandType = typeof(TCommand); | ||
|  | ||
| if (TryGetIntegrationDetails(CommandType.FullName, out var integrationId, out var dbTypeName)) | ||
| if (TryGetIntegrationDetails(Tracer.Instance.Settings.DisabledAdoNetCommandTypes, CommandType.FullName, out var integrationId, out var dbTypeName)) | 
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.
:sorry: pretty sure this was me
| [Fact] | ||
| public void CanRoundTripPathwayContext() | ||
| [Theory] | ||
| [CombinatorialData] | 
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.
😃
| Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing the following branches/commits: Execution-time benchmarks measure the whole time it takes to execute a program. And are intended to measure the one-off costs. Cases where the execution time results for the PR are worse than latest master results are shown in red. The following thresholds were used for comparing the execution times: 
 Note that these results are based on a single point-in-time result for each branch. For full results, see the dashboard. Graphs show the p99 interval based on the mean and StdDev of the test run, as well as the mean value of the run (shown as a diamond below the graph). gantt
    title Execution time (ms) FakeDbCommand (.NET Framework 4.8) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Bailout
    This PR (7744) - mean (83ms)  : 75, 90
     .   : milestone, 83,
    master - mean (80ms)  : 77, 83
     .   : milestone, 80,
    section Baseline
    This PR (7744) - mean (78ms)  : 72, 83
     .   : milestone, 78,
    master - mean (75ms)  : 71, 79
     .   : milestone, 75,
    section CallTarget+Inlining+NGEN
    This PR (7744) - mean (1,195ms)  : crit, 1144, 1246
     .   : crit, milestone, 1195,
    master - mean (1,099ms)  : 1039, 1160
     .   : milestone, 1099,
gantt
    title Execution time (ms) FakeDbCommand (.NET Core 3.1) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Bailout
    This PR (7744) - mean (118ms)  : 114, 122
     .   : milestone, 118,
    master - mean (118ms)  : 115, 122
     .   : milestone, 118,
    section Baseline
    This PR (7744) - mean (116ms)  : 111, 121
     .   : milestone, 116,
    master - mean (117ms)  : 112, 121
     .   : milestone, 117,
    section CallTarget+Inlining+NGEN
    This PR (7744) - mean (899ms)  : crit, 857, 942
     .   : crit, milestone, 899,
    master - mean (798ms)  : 773, 823
     .   : milestone, 798,
gantt
    title Execution time (ms) FakeDbCommand (.NET 6) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Bailout
    This PR (7744) - mean (104ms)  : 100, 107
     .   : milestone, 104,
    master - mean (105ms)  : 101, 109
     .   : milestone, 105,
    section Baseline
    This PR (7744) - mean (103ms)  : 99, 106
     .   : milestone, 103,
    master - mean (104ms)  : 101, 107
     .   : milestone, 104,
    section CallTarget+Inlining+NGEN
    This PR (7744) - mean (786ms)  : 723, 849
     .   : milestone, 786,
    master - mean (749ms)  : 717, 781
     .   : milestone, 749,
gantt
    title Execution time (ms) FakeDbCommand (.NET 8) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Bailout
    This PR (7744) - mean (102ms)  : 99, 105
     .   : milestone, 102,
    master - mean (103ms)  : 101, 106
     .   : milestone, 103,
    section Baseline
    This PR (7744) - mean (101ms)  : 98, 105
     .   : milestone, 101,
    master - mean (102ms)  : 99, 105
     .   : milestone, 102,
    section CallTarget+Inlining+NGEN
    This PR (7744) - mean (753ms)  : 714, 791
     .   : milestone, 753,
    master - mean (713ms)  : 694, 732
     .   : milestone, 713,
gantt
    title Execution time (ms) HttpMessageHandler (.NET Framework 4.8) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Bailout
    This PR (7744) - mean (197ms)  : 194, 199
     .   : milestone, 197,
    master - mean (197ms)  : 193, 201
     .   : milestone, 197,
    section Baseline
    This PR (7744) - mean (193ms)  : 189, 197
     .   : milestone, 193,
    master - mean (194ms)  : 190, 197
     .   : milestone, 194,
    section CallTarget+Inlining+NGEN
    This PR (7744) - mean (1,258ms)  : crit, 1188, 1327
     .   : crit, milestone, 1258,
    master - mean (1,185ms)  : 1112, 1259
     .   : milestone, 1185,
gantt
    title Execution time (ms) HttpMessageHandler (.NET Core 3.1) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Bailout
    This PR (7744) - mean (278ms)  : 274, 283
     .   : milestone, 278,
    master - mean (277ms)  : 273, 282
     .   : milestone, 277,
    section Baseline
    This PR (7744) - mean (278ms)  : 273, 283
     .   : milestone, 278,
    master - mean (277ms)  : 272, 283
     .   : milestone, 277,
    section CallTarget+Inlining+NGEN
    This PR (7744) - mean (1,005ms)  : crit, 933, 1078
     .   : crit, milestone, 1005,
    master - mean (947ms)  : 906, 988
     .   : milestone, 947,
gantt
    title Execution time (ms) HttpMessageHandler (.NET 6) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Bailout
    This PR (7744) - mean (269ms)  : 266, 273
     .   : milestone, 269,
    master - mean (270ms)  : 264, 275
     .   : milestone, 270,
    section Baseline
    This PR (7744) - mean (272ms)  : 266, 277
     .   : milestone, 272,
    master - mean (277ms)  : 260, 293
     .   : milestone, 277,
    section CallTarget+Inlining+NGEN
    This PR (7744) - mean (979ms)  : 935, 1024
     .   : milestone, 979,
    master - mean (940ms)  : 876, 1003
     .   : milestone, 940,
gantt
    title Execution time (ms) HttpMessageHandler (.NET 8) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Bailout
    This PR (7744) - mean (269ms)  : 266, 273
     .   : milestone, 269,
    master - mean (270ms)  : 266, 275
     .   : milestone, 270,
    section Baseline
    This PR (7744) - mean (270ms)  : 264, 277
     .   : milestone, 270,
    master - mean (271ms)  : 260, 282
     .   : milestone, 271,
    section CallTarget+Inlining+NGEN
    This PR (7744) - mean (947ms)  : crit, 900, 994
     .   : crit, milestone, 947,
    master - mean (860ms)  : 838, 882
     .   : milestone, 860,
 | 
Summary of changes
Updates a couple of places where we're calling
Tracer.Instancewhere we don't need toReason for change
In one of my other PRs I accidentally broke something that should only have affected integration tests, but a bunch of unit tests broke. It highlighted where they were using
Tracer.Instanceand setting the global tracer for tests. In other places, it revealed that code that tests that looked independent of other tests really wasn't...Calling
Tracer.Instancepotentially does a lot of work, as it initializes the tracer. It's also hard to follow if we're making static calls out in places we don't need to. So just pass through the settings we want instead.Implementation details
Instead of calling
Tracer.Instance.Settings, use the value ofTracerorTracerSettingsthat's already available wherever possible. It makes the tests cleaner too.Test coverage
Same coverage, just a bit cleaner
Other details
Included as part of the config stack, just because I already refactored some of this code, and can't be bothered to faff with merge conflicts:
https://datadoghq.atlassian.net/browse/LANGPLAT-819
MutableSettingsfromTracerSettings#7522MutableSettingson dynamic config changes #7525DefaultServiceNametoMutableSettings#7530PerTraceSettings.GetServiceName()#7532TracerSettingsto useMutableSettingswhere appropriate #7543IsIntegrationEnabled(),IsErrorStatusCode(), andGetIntegrationAnalyticsSampleRate()#7544DictionaryExtensions.SequenceEqual#7722SettingsManagerfor managing mutable settings and ExporterSettings #7695TracerSettingswhich can change at runtime #7723MutableSettingsandExporterSettingswithout rebuilding #7724Tracer.Instanceif we don't need to #7744 👈