Debugger: add upload metadata fields to SymDB upload event message#8590
Conversation
Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing This PR (8590) 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 (8590) - mean (75ms) : 71, 78
master - mean (74ms) : 70, 77
section Bailout
This PR (8590) - mean (77ms) : 74, 80
master - mean (80ms) : 76, 84
section CallTarget+Inlining+NGEN
This PR (8590) - mean (1,104ms) : 1033, 1176
master - mean (1,093ms) : 1040, 1146
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 (8590) - mean (116ms) : 110, 121
master - mean (118ms) : 112, 124
section Bailout
This PR (8590) - mean (116ms) : 113, 118
master - mean (117ms) : 112, 123
section CallTarget+Inlining+NGEN
This PR (8590) - mean (794ms) : 764, 823
master - mean (791ms) : 767, 814
FakeDbCommand (.NET 6)gantt
title Execution time (ms) FakeDbCommand (.NET 6)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8590) - mean (101ms) : 97, 105
master - mean (101ms) : 98, 105
section Bailout
This PR (8590) - mean (104ms) : 98, 109
master - mean (104ms) : 99, 110
section CallTarget+Inlining+NGEN
This PR (8590) - mean (949ms) : 912, 986
master - mean (945ms) : 905, 985
FakeDbCommand (.NET 8)gantt
title Execution time (ms) FakeDbCommand (.NET 8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8590) - mean (101ms) : 97, 105
master - mean (101ms) : 96, 106
section Bailout
This PR (8590) - mean (101ms) : 99, 103
master - mean (101ms) : 99, 104
section CallTarget+Inlining+NGEN
This PR (8590) - mean (826ms) : 793, 860
master - mean (823ms) : 781, 866
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 (8590) - mean (190ms) : 187, 193
master - mean (190ms) : 187, 193
section Bailout
This PR (8590) - mean (194ms) : 192, 196
master - mean (194ms) : 192, 195
section CallTarget+Inlining+NGEN
This PR (8590) - mean (1,160ms) : 1111, 1210
master - mean (1,161ms) : 1119, 1203
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 (8590) - mean (272ms) : 268, 276
master - mean (272ms) : 268, 276
section Bailout
This PR (8590) - mean (272ms) : 269, 275
master - mean (272ms) : 269, 275
section CallTarget+Inlining+NGEN
This PR (8590) - mean (926ms) : 906, 946
master - mean (925ms) : 909, 942
HttpMessageHandler (.NET 6)gantt
title Execution time (ms) HttpMessageHandler (.NET 6)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8590) - mean (266ms) : 263, 270
master - mean (266ms) : 263, 270
section Bailout
This PR (8590) - mean (275ms) : 266, 283
master - mean (266ms) : 263, 269
section CallTarget+Inlining+NGEN
This PR (8590) - mean (1,151ms) : 1102, 1200
master - mean (1,117ms) : 1047, 1186
HttpMessageHandler (.NET 8)gantt
title Execution time (ms) HttpMessageHandler (.NET 8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8590) - mean (276ms) : 257, 294
master - mean (263ms) : 260, 267
section Bailout
This PR (8590) - mean (283ms) : crit, 266, 301
master - mean (264ms) : 262, 266
section CallTarget+Inlining+NGEN
This PR (8590) - mean (1,029ms) : 990, 1068
master - mean (1,014ms) : 976, 1052
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
BenchmarksBenchmark execution time: 2026-05-11 20:41:54 Comparing candidate commit 3487c6f in PR branch Some scenarios are present only in baseline or only in candidate runs. If you didn't create or remove some scenarios in your branch, this maybe a sign of crashed benchmarks 💥💥💥 Scenarios present only in baseline:
Found 4 performance improvements and 3 performance regressions! Performance is the same for 45 metrics, 20 unstable metrics, 88 known flaky benchmarks, 38 flaky benchmarks without significant changes.
|
433f256 to
2aa8f23
Compare
dudikeleti
left a comment
There was a problem hiding this comment.
Thanks! I left a few comments / questions.
For symdb uploads we were sending the event
{
...
"debugger.type": "symdb"
}
I think this was useless; that's not where the EvP pipeline looks for
the type for routing (things were still working because of a fallback
looking for attachments). The other tracers (Java, Python, Ruby) all
put "type" at the root of the SymDB upload event message, not behind
a "debugger.<key>" prefix. Align with them by moving "type" to the
root.
…d attachment Add the following fields to the SymDB upload event message that accompanies each multipart upload (camelCase, matching the rest of the EvP event schema): - "version" (top-level): the service version - "language" (top-level): "dotnet" - "uploadId" (top-level): a UUID generated once per SymbolsUploader instance, shared by all batches uploaded by the instance - "batchNum" (top-level): 1-indexed counter incremented per upload - "final" (top-level): always false; the .NET tracer continuously uploads new code as assemblies get loaded, so there is no defined end-of-upload point - "attachmentSize" (top-level): size in bytes of the (compressed) attachment payload Also add the same metadata to the gzipped attachment Root (snake_case to match the rest of the attachment scope schema): - "upload_id" - "batch_num" - "final" uploadId/batchNum are computed in SymbolsUploader once per batch (rebuilding the JSON prefix per batch) and threaded into SymbolUploadApi.SendBatchAsync so both the attachment and the event JSON carry the same values. SymbolUploadApi no longer tracks its own batch counter. Some of these fields are new, to be used by the backend in the future. Others duplicate info that was already included in the attachment; by duplicating some metadata out of the SymDB attachment body into the EvP event body, the backend can populate per-attachment bookkeeping without downloading the attachment.
2aa8f23 to
3487c6f
Compare
dudikeleti
left a comment
There was a problem hiding this comment.
Thank you!
Just to confirm, are there already system tests for this, or do we need to add them?
|
I'm adding system tests in DataDog/system-tests#6887 |
Add the following fields to the SymDB upload event message that
accompanies each multipart upload (camelCase, matching the rest of
the EvP event schema):
instance, shared by all batches uploaded by the instance
uploads new code as assemblies get loaded, so there is no defined
end-of-upload point
attachment payload
Also add the same metadata to the gzipped attachment Root
(snake_case to match the rest of the attachment scope schema):
uploadId/batchNum are computed in SymbolsUploader once per batch
(rebuilding the JSON prefix per batch) and threaded into
SymbolUploadApi.SendBatchAsync so both the attachment and the event
JSON carry the same values. SymbolUploadApi no longer tracks its own
batch counter.
Some of these fields are new, to be used by the backend in the future.
Others duplicate info that was already included in the attachment; by
duplicating some metadata out of the SymDB attachment body into the EvP
event body, the backend can populate per-attachment bookkeeping without
downloading the attachment.