[chore][processor/dynamic_sampling] add concurrent ConsumeTraces benchmarks

[MikeGoldsmith]

Description

All existing benchmarks drive ConsumeTraces from a single goroutine, but the collector calls it concurrently from receivers and pipelines, and the processor serializes most of its work behind one mutex. This adds concurrent benchmarks so multi-core scaling is measured rather than assumed, and gives the planned lock-restructuring work a baseline and acceptance test.

BenchmarkConsumeTraces_Parallel covers the steady-state paths (new traces, appends to pending traces, decision-cache hits for both outcomes) and BenchmarkConsumeTraces_ParallelMixed runs ingest racing timer-driven decisions. Run with -cpu=1,4,8,16. The file header documents a -mutexprofile recipe for attributing lock wait.

Measured today (spans/sec, mean of 3, Apple M4 Pro):

path	1 cpu	4 cpu	8 cpu	16 cpu
new_traces	1.35M	2.56M	2.58M	2.61M
append_to_pending	2.28M	3.40M	3.55M	3.57M
cache_hit_sampled	2.25M	2.81M	2.85M	2.81M
cache_hit_dropped	30.1M	23.8M	23.1M	22.6M
mixed ingest + decisions	1.16M	1.79M	1.63M	1.42M

The numbers show the ceiling clearly. Every path stops scaling at 4 cores, the cheapest path (cache-hit drop) gets slower under contention, and the mixed workload regresses past 4 cores once decision timers compete for the same lock.

Link to tracking issue

Refs #49311

Testing

• This PR is benchmarks; the table above is the output of running them.
• Full test suite and lint pass.

Documentation

Run instructions and interpretation guidance are in the file header. Test-only change, no changelog entry.

Authorship

• I, a human, wrote this pull request description myself.

[opentelemetry-pr-dashboard]

Pull request dashboard status

Merged · refreshed 2026-08-05 10:38 UTC

Status above doesn't look right?

• Anything look wrong? Report it with what you expected; it helps us improve the dashboard.