1 Commits
Author SHA1 Message Date
romanettandClaude Opus 5.5 df6adec1af Refresh server benchmarks for 2.0.2: GC modes, processor placement, delivery (#4868)
Closes #4842.

Measures the items that `docs/Benchmarks.md` listed under *Open
measurements* and makes every published table reproducible from
checked-in files.

All runs: `master` f6b27025a, AMD Ryzen AI 9 HX 370 (4 Zen 5 + 8 Zen 5c
cores, 24 logical), 64 GB, Windows 11 26300, Balanced power plan, .NET
SDK 10.0.402 / runtime 10.0.13. Each table has 5 rounds per variant,
alternated and reversed every other round, and reports the median with
its min–max range.

## Docs
- **Reference Read table** re-run with ranges. The 2026-10-18 single
runs move to a *Historical results* subsection.
- .NET pinned to 4 logical processors: 440k req/s at 8.9 µs CPU per
Read.
  - open62541: 137k req/s at 7.3 µs.
  - .NET on 24 logical processors: 600k req/s at 22.9 µs.
- **Garbage collector modes**: workstation, Server GC with DATAS, and
Server GC with fixed heaps, on `native-read`, `read` and `events`.
- Server GC gave 45–89 % more throughput than workstation GC.
Workstation GC paused the server for 30–46 % of the window.
- Turning DATAS off cut GC pauses 4.6–8× at 1.9–2.8× the working set,
with no throughput difference beyond the ranges.
- **Processor placement** on the hybrid CPU, with and without
SignAndEncrypt.
- Server on the Zen 5 logical processors (`0xFF`): median throughput
within 7 % of the default placement at about half the CPU per Read (11.7
vs 22.9 µs).
- **Publish and event delivery** on the merged 2.0.2 master: delivered
share, latency, CPU and allocation per notification, and GC pause.
- **Recommended baseline** now cites these measurements.
`ServerScalability.md` GC and affinity paragraphs are updated to match.
- **Open measurements** now lists only what is still unmeasured: Linux,
Intel hybrid CPUs, a dedicated host, and session establishment and
scaling.

## Regression found (documented, not fixed here)
The 50 sessions × 15 subscriptions × 600 items publish shape from #4829
now delivers only about 26 % of the expected notifications.

| Commit | Delivered | Server CPU / notification |
|---|--:|--:|
| `37a2a831f` (#4829 merge) | 93 % | 3.9 µs |
| `f6b27025a` (master) | 23 % | 46 µs |

Both rows use the same harness arguments. A `git bisect` finds 65a67dd2f
(#4757) as the first bad commit: its parent 0edc3b55a delivers 98 % at
2.8 µs, while 65a67dd2f delivers 6 % at 94 µs. The fix is being worked
on separately.

## Tooling
- `perf/variants.sh` runs one harness build under several
configurations, given as `name|env|args` lines. It discards and repeats
any run that overlaps another test host or load harness.
- `perf/variants-summary.ps1` prints the median and range of each metric
per variant.
- `perf/benchmarks/*.txt` holds the variant and scenario files for each
table.
- `perf/README.md` documents all of the above.

## Test plan
- [x] All four batches ran with the checked-in files. 2 of 140 runs were
discarded because of foreign load; none failed.
- [x] The summaries reproduce the tabulated numbers.
- [x] CRLF line endings preserved in the edited docs.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-21 16:20:04 +00:00