Minor and performance updates for client-side-stats#8822
Conversation
BenchmarksBenchmark execution time: 2026-06-26 09:27:12 Comparing candidate commit ab84d18 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 72 metrics, 0 unstable metrics, 63 known flaky benchmarks, 63 flaky benchmarks without significant changes.
|
Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing This PR (8822) and master. ✅ No regressions detected - check the details below Full Metrics ComparisonFakeDbCommand
HttpMessageHandler
Comparison explanationExecution-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 highlighted 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). Duration chartsFakeDbCommand (.NET Framework 4.8)gantt
title Execution time (ms) FakeDbCommand (.NET Framework 4.8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8822) - mean (70ms) : 68, 72
master - mean (70ms) : 68, 73
section Bailout
This PR (8822) - mean (76ms) : 73, 80
master - mean (74ms) : 73, 76
section CallTarget+Inlining+NGEN
This PR (8822) - mean (1,083ms) : 1040, 1126
master - mean (1,083ms) : 1033, 1133
FakeDbCommand (.NET Core 3.1)gantt
title Execution time (ms) FakeDbCommand (.NET Core 3.1)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8822) - mean (110ms) : 105, 115
master - mean (109ms) : 106, 113
section Bailout
This PR (8822) - mean (114ms) : 109, 119
master - mean (110ms) : 109, 112
section CallTarget+Inlining+NGEN
This PR (8822) - mean (772ms) : 756, 788
master - mean (774ms) : 754, 795
FakeDbCommand (.NET 6)gantt
title Execution time (ms) FakeDbCommand (.NET 6)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8822) - mean (97ms) : 94, 100
master - mean (97ms) : 94, 100
section Bailout
This PR (8822) - mean (102ms) : 96, 108
master - mean (98ms) : 96, 99
section CallTarget+Inlining+NGEN
This PR (8822) - mean (939ms) : 898, 980
master - mean (942ms) : 900, 984
FakeDbCommand (.NET 8)gantt
title Execution time (ms) FakeDbCommand (.NET 8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8822) - mean (96ms) : 93, 99
master - mean (95ms) : 92, 97
section Bailout
This PR (8822) - mean (96ms) : 95, 98
master - mean (96ms) : 94, 98
section CallTarget+Inlining+NGEN
This PR (8822) - mean (814ms) : 769, 859
master - mean (813ms) : 777, 849
HttpMessageHandler (.NET Framework 4.8)gantt
title Execution time (ms) HttpMessageHandler (.NET Framework 4.8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8822) - mean (202ms) : 197, 206
master - mean (205ms) : 200, 210
section Bailout
This PR (8822) - mean (206ms) : 203, 210
master - mean (209ms) : 204, 213
section CallTarget+Inlining+NGEN
This PR (8822) - mean (1,209ms) : 1165, 1252
master - mean (1,216ms) : 1169, 1264
HttpMessageHandler (.NET Core 3.1)gantt
title Execution time (ms) HttpMessageHandler (.NET Core 3.1)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8822) - mean (290ms) : 283, 298
master - mean (293ms) : 285, 301
section Bailout
This PR (8822) - mean (289ms) : 282, 296
master - mean (295ms) : 288, 301
section CallTarget+Inlining+NGEN
This PR (8822) - mean (974ms) : 953, 996
master - mean (986ms) : 966, 1006
HttpMessageHandler (.NET 6)gantt
title Execution time (ms) HttpMessageHandler (.NET 6)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8822) - mean (283ms) : 277, 289
master - mean (288ms) : 282, 294
section Bailout
This PR (8822) - mean (282ms) : 278, 287
master - mean (287ms) : 282, 291
section CallTarget+Inlining+NGEN
This PR (8822) - mean (1,172ms) : 1137, 1207
master - mean (1,173ms) : 1138, 1208
HttpMessageHandler (.NET 8)gantt
title Execution time (ms) HttpMessageHandler (.NET 8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8822) - mean (281ms) : 274, 288
master - mean (283ms) : 274, 291
section Bailout
This PR (8822) - mean (281ms) : 275, 286
master - mean (283ms) : 277, 288
section CallTarget+Inlining+NGEN
This PR (8822) - mean (1,049ms) : 1003, 1094
master - mean (1,049ms) : 994, 1104
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ba84f2d to
ab84d18
Compare
…ide-Stats computation (#8766) ## Summary of changes Implements span-derived primary tags (also called "Additional metric tags") ## Reason for change This is a feature requested by customers, and defined in [the RFC](https://datadoghq.atlassian.net/wiki/spaces/APM/history/6482919540/PENDING+Span-Derived+Primary+Tags+-+V1) ## Implementation details - Add `DD_TRACE_STATS_ADDITIONAL_TAGS` for controlling which span-tags to include as metric dimensions in client-side-stats - This is an experimental feature, so is gated on `DD_TRACE_EXPERIMENTAL_FEATURES_ENABLED` currently - Include the defined tags as additional dimensions in the metric key (similar to peer tags) - Apply cardinality limits to avoid memory leaks - NOTE: the cardinality limits implemented here are somewhat superseded by [a subsequent RFC](https://datadoghq.atlassian.net/wiki/spaces/APM/pages/6821151019/PENDING+Cardinality+Limits), and so are only partially implemented here. ## Test coverage - Added unit tests for all the behaviour - System tests TBC - once they're implemented, I'll enable them and confirm they're worked ## Other details Some aspects of the RFC are missing/modified based on other discussions - The telemetry metric in the span tags RFC is not defined, we will add the cardinality limit version instead. - The required logging will be added as part of the cardinality RFC implementation - Cardinality protection doesn't entirely match the RFC, as it follows the later RFC Part of a stack - #8822 - #8766 👈 - #8823 - #8824 https://datadoghq.atlassian.net/browse/APMLP-1446 --------- Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
## Summary of changes Adds support for adding `DD_TAGS` as span-derived primary tags (AKA Additional tags) in Client Side Stats ## Reason for change Implements [the RFC](https://datadoghq.atlassian.net/wiki/spaces/APM/pages/6607667207/PENDING+DD_TAGS+Derived+Primary+Tags) for adding `DD_TAGS` to the client-side stats payload. ## Implementation details Relatively simple: we just thread any `DD_TAGS` value through to the payload, and the backend/agent then ensures they're added as span-derived primary tags. There's no cardinality issues at play here, which simplifies things, and we can just include them in every payload ## Test coverage Added some unit tests, system tests to follow... ## Other details Part of a stack - #8822 - #8766 - https://github.com/DataDog/dd-trace-dotnet/pull/8823👈 - #8824 https://datadoghq.atlassian.net/browse/APMLP-1446
## Summary of changes Implements the Client-Side Stats [cardinality control RFC](https://datadoghq.atlassian.net/wiki/spaces/APM/pages/6821151019/PENDING+Cardinality+Limits) ## Reason for change Currently, we have a risk of unbounded memory growth caused by cardinality explosion. This has not been a big issue so far as CSS is off by default for .NET. However, resource name explosion (in particular), as well as span-derived primary tags and peer tags have the potential to cause OOM issues. This PR adds strict (configurable) caps to prevent issues from runaway memory growth. ## Implementation details Largely broken into separate distinct commits - Convert `StatsAggregationKey` to `readonly record struct`, seeing as that's basically what it was anyway - Make `IsTraceRoot` nullable (required for "overflow bucket") - Make resource length limit configurable (to support "big_resource" feature from agent) - Add per-field cardinality limitation to resource, httpendoint, peertags, additional tags - Per-field limits stop a single very high cardinality field rendering everything else useless - Only added to these 4 fields for now, but we can expand if necessary - Add whole-key cardinality limit - Essentially a cap on the maximum number of buckets we'll allocate - All additional stats flow into an "overflow" bucket - Add telemetry/heath-metrics/logging for tracking overflow occurences - Add some tests ## Test coverage Added a bunch of unit tests. Waiting on system tests to confirm the implementation. ## Other details Part of a stack - #8822 - #8766 - #8823 - #8824 👈 https://datadoghq.atlassian.net/browse/APMLP-1446
Summary of changes
[TestingAndPrivateOnly]Reason for change
Minor tweaks (mostly perf) before adding the additional client-side-stats features
Implementation details
Mostly self-evident, written as distinct commits. The most interesting one is avoiding the additional interpolated string when encoding peer_tags. We also avoid re-encoding the tags seeing as we already do that work up front
Test coverage
Covered by existing tests, this is all refactoring
Other details
Part of a client-side stats stack of PRs.
DD_TAGSin Client-Side stats #8823https://datadoghq.atlassian.net/browse/APMLP-1446