Add support for RabbitMQ v7 #6479
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
andrewlock
added
area:tracer
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.6.2)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6479) - mean (69ms) : 66, 72
. : milestone, 69,
master - mean (69ms) : 66, 72
. : milestone, 69,
section CallTarget+Inlining+NGEN
This PR (6479) - mean (981ms) : 959, 1003
. : milestone, 981,
master - mean (975ms) : 950, 1001
. : milestone, 975,
gantt
title Execution time (ms) FakeDbCommand (.NET Core 3.1)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6479) - mean (107ms) : 105, 109
. : milestone, 107,
master - mean (108ms) : 105, 110
. : milestone, 108,
section CallTarget+Inlining+NGEN
This PR (6479) - mean (681ms) : 669, 694
. : milestone, 681,
master - mean (679ms) : 664, 694
. : milestone, 679,
gantt
title Execution time (ms) FakeDbCommand (.NET 6)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6479) - mean (91ms) : 89, 93
. : milestone, 91,
master - mean (91ms) : 90, 93
. : milestone, 91,
section CallTarget+Inlining+NGEN
This PR (6479) - mean (636ms) : 620, 652
. : milestone, 636,
master - mean (635ms) : 619, 651
. : milestone, 635,
gantt
title Execution time (ms) HttpMessageHandler (.NET Framework 4.6.2)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6479) - mean (190ms) : 186, 193
. : milestone, 190,
master - mean (194ms) : 189, 198
. : milestone, 194,
section CallTarget+Inlining+NGEN
This PR (6479) - mean (1,092ms) : 1064, 1119
. : milestone, 1092,
master - mean (1,094ms) : 1067, 1122
. : milestone, 1094,
gantt
title Execution time (ms) HttpMessageHandler (.NET Core 3.1)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6479) - mean (275ms) : 271, 280
. : milestone, 275,
master - mean (277ms) : 273, 281
. : milestone, 277,
section CallTarget+Inlining+NGEN
This PR (6479) - mean (868ms) : 843, 893
. : milestone, 868,
master - mean (871ms) : 849, 892
. : milestone, 871,
gantt
title Execution time (ms) HttpMessageHandler (.NET 6)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6479) - mean (264ms) : 260, 269
. : milestone, 264,
master - mean (267ms) : 263, 271
. : milestone, 267,
section CallTarget+Inlining+NGEN
This PR (6479) - mean (849ms) : 819, 879
. : milestone, 849,
master - mean (855ms) : 820, 889
. : milestone, 855,
|
Datadog ReportBranch report: ❌ 356 Failed (1 Known Flaky), 587296 Passed, 5483 Skipped, 48h 23m 19.31s Total Time ❌ Failed Tests (356)
|
Benchmarks Report for tracer 🐌Benchmarks for #6479 compared to master:
The following thresholds were used for comparing the benchmark speeds:
Allocation changes below 0.5% are ignored. Benchmark detailsBenchmarks.Trace.ActivityBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.AgentWriterBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.AspNetCoreBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.DbCommandBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.ElasticsearchBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.GraphQLBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.HttpClientBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.ILoggerBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.Log4netBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.NLogBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.RedisBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.SerilogBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.SpanBenchmark - Slower
|
| Benchmark | diff/base | Base Median (ns) | Diff Median (ns) | Modality |
|---|---|---|---|---|
| Benchmarks.Trace.SpanBenchmark.StartFinishSpan‑net6.0 | 1.193 | 397.43 | 474.03 |
Raw results
| Branch | Method | Toolchain | Mean | StdError | StdDev | Gen 0 | Gen 1 | Gen 2 | Allocated |
|---|---|---|---|---|---|---|---|---|---|
| master | StartFinishSpan |
net6.0 | 398ns | 0.155ns | 0.602ns | 0.00819 | 0 | 0 | 576 B |
| master | StartFinishSpan |
netcoreapp3.1 | 615ns | 0.451ns | 1.75ns | 0.00767 | 0 | 0 | 576 B |
| master | StartFinishSpan |
net472 | 700ns | 0.374ns | 1.4ns | 0.0917 | 0 | 0 | 578 B |
| master | StartFinishScope |
net6.0 | 542ns | 0.325ns | 1.22ns | 0.00975 | 0 | 0 | 696 B |
| master | StartFinishScope |
netcoreapp3.1 | 718ns | 0.412ns | 1.49ns | 0.00946 | 0 | 0 | 696 B |
| master | StartFinishScope |
net472 | 884ns | 0.661ns | 2.56ns | 0.104 | 0 | 0 | 658 B |
| #6479 | StartFinishSpan |
net6.0 | 474ns | 0.28ns | 1.08ns | 0.00808 | 0 | 0 | 576 B |
| #6479 | StartFinishSpan |
netcoreapp3.1 | 572ns | 0.484ns | 1.87ns | 0.00768 | 0 | 0 | 576 B |
| #6479 | StartFinishSpan |
net472 | 722ns | 0.79ns | 2.95ns | 0.0916 | 0 | 0 | 578 B |
| #6479 | StartFinishScope |
net6.0 | 516ns | 0.297ns | 1.07ns | 0.00967 | 0 | 0 | 696 B |
| #6479 | StartFinishScope |
netcoreapp3.1 | 713ns | 0.502ns | 1.95ns | 0.00931 | 0 | 0 | 696 B |
| #6479 | StartFinishScope |
net472 | 929ns | 0.819ns | 3.17ns | 0.104 | 0 | 0 | 658 B |
Benchmarks.Trace.TraceAnnotationsBenchmark - Same speed ✔️ Same allocations ✔️
Raw results
| Branch | Method | Toolchain | Mean | StdError | StdDev | Gen 0 | Gen 1 | Gen 2 | Allocated |
|---|---|---|---|---|---|---|---|---|---|
| master | RunOnMethodBegin |
net6.0 | 667ns | 0.353ns | 1.32ns | 0.00969 | 0 | 0 | 696 B |
| master | RunOnMethodBegin |
netcoreapp3.1 | 876ns | 0.706ns | 2.74ns | 0.00922 | 0 | 0 | 696 B |
| master | RunOnMethodBegin |
net472 | 1.07μs | 0.659ns | 2.55ns | 0.104 | 0 | 0 | 658 B |
| #6479 | RunOnMethodBegin |
net6.0 | 665ns | 0.363ns | 1.41ns | 0.00965 | 0 | 0 | 696 B |
| #6479 | RunOnMethodBegin |
netcoreapp3.1 | 884ns | 0.34ns | 1.32ns | 0.00926 | 0 | 0 | 696 B |
| #6479 | RunOnMethodBegin |
net472 | 1.04μs | 0.709ns | 2.75ns | 0.105 | 0 | 0 | 658 B |
andrewlock
force-pushed
the
andrew/update-rabbitmq
branch
from
c47a319 to
c2b1675
Compare
andrewlock
force-pushed
the
andrew/value-task-support
branch
from
ffc922e to
457a93f
Compare
andrewlock
force-pushed
the
andrew/update-rabbitmq
branch
from
c2b1675 to
288fb51
Compare
andrewlock
force-pushed
the
andrew/value-task-support
branch
from
457a93f to
6c8dbe5
Compare
andrewlock
force-pushed
the
andrew/update-rabbitmq
branch
from
288fb51 to
882ea95
Compare
andrewlock
force-pushed
the
andrew/value-task-support
branch
from
6c8dbe5 to
a73c2c7
Compare
andrewlock
force-pushed
the
andrew/update-rabbitmq
branch
from
882ea95 to
8443b2e
Compare
andrewlock
added a commit
that referenced
this pull request
Jan 9, 2025
…#6480) ## Summary of changes Add support for correct `CallTarget` instrumentation of methods that return `ValueTask` in < .NET Core 3.1 or .NET Framework ## Reason for change We already support instrumenting methods that returns `ValueTask` in .NET Core 3.1. However, in .NET Framework or .NET Standard 2.0, this support is [provided by a package](https://www.nuget.org/packages/System.Threading.Tasks.Extensions), and we currently _don't_ support instrumenting these methods. Or rather, we just ignore the `OnAsyncMethodEnd` in integrations in these cases. ## Implementation details We already support `ValueTask` in more recent frameworks, and the support is very similar to our `Task` support. Unfortunately, in .NET FX we can't reference the `ValueTask` type itself. To work around this, we do the following: - Detect that the return type is `ValueTask` or `ValueTask<T>` either by loading the type directly (.NET Core) or checking the type name (.NET Framework) - Duck-type the `ValueTask` to read the `IsCompletedSuccessfully` value. - If this is true, the task is already completed synchronously, and we can simply call the target method. - For `ValueTask<T>` we duck type `Result` and read that directly too. - If it _hasn't_ completed, we need to extract the `Task` from it. - Duck typing is used again to extract the `Task()` for uncompleted `ValueTask` - At this point, it's mostly a copy-paste of the existing `Task` integrations - Once the integration returns, we need to create a "new" `ValueTask` instead from the previous one - The semantics of `ValueTask` _require_ that we create a "fresh" one, we can't just "reuse" the one we got originally, because we've already retrieved the result/ awaited the inner task - Have to use `Activator`/`DynamicMethod` for this > [!WARNING] > The existing `ValueTask`/`ValueTask<>` and `Task`/`Task<>` integrations are written quite differently, and I'm not entirely sure why 🤔 Given the `ContinuationAction()` methods for both these cases operate on `Task`, I based on the new `ValueTask` integrations on the `Task` integrations, but if anyone has reasons why it shouldn't be, I'm all ears! ## Test coverage - Added `Task` and `ValueTask` tests to the `CallTargetNativeTests` integration tests. Previously we were only testing a single `Task` example, and that was somewhat insufficient - Update the `CallTargetNativeTests` to explicitly assert that the `OnAsyncMethodEnd` methods are called for `Task` / `ValueTask` method integrations. As we provide _both_ methods in our target integration, we were silently calling the wrong one for .NET FX - Prior to the fix in this PR, these updated tests would fail on < .NET Core 3.0 and .NET FX - Run the `ValueTaskAsyncContinutationGenerator` unit tests on all TFMs, not just .NET Core 3.1 - Unit tests for the `ValueTaskHelper` for checking if a type is a `ValueTask` - Unit tests for the `ValueTaskActivator` for creating a `ValueTask` from a `Task` or `Task<T>` - Verified it fixes the issues I was seeing in the RabbitMQ integration - #6479 ## Other details Required for - #6479
andrewlock
force-pushed
the
andrew/update-rabbitmq
branch
3 times, most recently
from
a3bd662 to
3059d67
Compare
bouwkast
approved these changes
Jan 14, 2025
....Trace/ClrProfiler/AutoInstrumentation/RabbitMQ/BasicPublishAsyncCachedStringsIntegration.cs
Outdated
Show resolved
Hide resolved
…tMQ/BasicPublishAsyncCachedStringsIntegration.cs
andrewlock
force-pushed
the
andrew/update-rabbitmq
branch
from
127cf20 to
09e7eb4
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary of changes
Adds support for RabbitMQ v7
Reason for change
We want to support the latest versions of packages. 7.x.x was released ~6 weeks ago, with significant changes to both the public API and the internal API (which is probably why it hasn't been explicitly requested yet).
Implementation details
This one took a lot of work. In summary:
BasicPropertiesbecause nowIReadOnlyBasicPropertiesis null, which means we can't easily add the headers if they're not provided (to propagate context).#if RABBITMQ_7_0my way in the existing methods, but was impossible to follow, so split into -pre and -post v7 methods instead.Test coverage
We get the same overall snapshots for v7 as we do for v6, so 🤞 Did an "all TFMs, all versions" run here (and a previous one for DSM)
Other details
Stacked on:
[DuckPropertyOrField]#6463ValueTaskin .NET FX and < .NET Core 3.1 #6480Note
This PR actually highlighted a current limitation in our CallTarget instrumentation. If an API uses
ValueTask, which comes from a library rather than being built-in (i.e. it's netfx or < .NET Core 3.1) then we don't instrument it correctly. Originally I worked around it, but there's a "proper" fix in #6480. Assuming that actually works and is merged, then we don't need the workaround, otherwise I can re-enable it.