Add a repeatable performance and scale benchmark suite

[lan17]

Priority

P2 — Medium — measurement infrastructure for performance-sensitive work, not a production correctness blocker by itself.

Current state

The original issue said DialCache had no committed benchmark command. That is stale: pnpm benchmark:request-local now runs a checked-in harness covering sequential request-local hits, request-local coalescing, and instance-scoped process coalescing with semantic fallback-count assertions.

Current evidence:

• Committed benchmark command
• Current three-scenario harness
• CI does not run benchmark smoke

The existing timings are informational. There is still no machine-readable output, environment capture, latency distribution, Redis/payload matrix, metrics comparison, heap/allocation reporting, or regression threshold.

Recommended phased scope

Phase 1 — comparable harness

• Add machine-readable JSON alongside readable output.
• Record Node, platform, architecture, dependency/Redis versions, iteration counts, and relevant configuration.
• Cover representative local hit/miss paths with metrics disabled and enabled.
• Cover tracked and untracked Redis read/write paths at a small representative payload matrix.
• Add a tiny semantic CI smoke run; do not make noisy timing thresholds gate CI.

Phase 2 — only when a concrete design needs evidence

Add focused scenarios for the issue being evaluated rather than building every possible scale test up front. Cluster skew, heap profiling, failure injection, compression, and large batch matrices belong here.

Dependencies and ordering

• This benchmark work is not required for an initial controlled production trial.
• Use this harness before choosing performance-sensitive defaults or implementing Make zero local capacity consistent and evaluate byte-aware limits #40, Establish a local-hit performance budget and remove avoidable hot-path work #43, or Add thresholded client-side compression for Redis payloads #60.
• Keep lower-copy Redis protocol research in Benchmark lower-copy Redis protocol alternatives for large payloads #37.

Acceptance criteria for Phase 1

• Reproducible command with JSON and human-readable output.
• Captured environment and configuration.
• Local hit/miss and tracked/untracked Redis coverage.
• Metrics-on/off comparison and representative payload sizes.
• Deterministic semantic assertions.
• Lightweight CI smoke without unstable performance gates.
• Baselines recorded before any regression budget is selected.