Chapter 22 — From Microbenchmark to Production Capacity Evidence

Chapter objective: After this chapter, a developer can select one DSM hot path, fix the JMH environment and parameters, retain raw JSON, and draw a capacity conclusion only under comparable conditions.

Learning objectives

1. Distinguish benchmark-harness smoke, microbenchmark result, and production capacity.
2. Select fixtures for Register, Lease, CRDT, ChangeStream, and security.
3. Record JDK, CPU, parameters, units, and raw result.
4. Separate throughput, latency distribution, and distributed end-to-end performance questions.

Prerequisites

• Backpressure from Chapter 13 and metrics from Chapter 19 are complete.
• Maven/JMH can run.
• A microbenchmark excludes production network, GC configuration, business payloads, and dependencies.

Case progress

"Can DSM handle the traffic?" is too broad for one measurement. The fulfillment team separates RecordCodec latency, Register get, Lease renew, CRDT apply/merge, ChangeStream overflow, and secure-envelope overhead into named hot paths.

Evidence chain for a capacity conclusion

The benchmark module contains:

• RecordCodecLatency, ProtobufSerializationLatency
• RegisterGetLatency
• LeaseRenewThroughput
• CrdtApplyThroughput, CrdtMergeThroughput
• ChangeStreamOverflowPolicyThroughput
• SecureEnvelopeEncryptionOverhead
• HLC, striped-lock, and QoS-scheduler hot paths

Each fixture answers only the local question in its name.

Smoke run and measurement run

BenchmarkHarnessTest checks request defaults, parameter validation, and JSON structure. A short JMH run proves the harness executes; insufficient warmup, forks, or measurement time makes its numbers unsuitable for a capacity commitment.

Reproducible smoke commands:

cd submodule/dsm
mvn -q -pl dsm-benchmark -am test
mvn -q -pl dsm-benchmark -DskipTests exec:exec \
  -Dbenchmark.include=RegisterGetLatency \
  -Dbenchmark.warmupIterations=0 \
  -Dbenchmark.measurementIterations=1 \
  -Dbenchmark.measurementTimeMs=100 \
  -Dbenchmark.forks=0

This is a CI/teaching smoke configuration rather than a recommended reporting configuration.

Required result-card fields

Copying one average discards units, error, percentiles, and run conditions.

From microbenchmark to capacity plan

Microbenchmarks reveal hot-path regressions. Production capacity also includes entity size and key distribution, node count, latency/loss, repair traffic, GC, contention, security overhead, observation backends, and workload peaks. Final load tests use independent processes in a production-like environment.

Counterexample and fault injection

• Publish a 100 ms forks=0 smoke number as an SLA and identify missing conditions.
• Compare different JDK/CPU runs without environment records and observe irreproducibility.
• Infer cross-node repair throughput from RegisterGetLatency and identify the execution mismatch.
• Delete the JMH JSON while retaining a Markdown number and observe loss of raw evidence.

Experiment

Run the harness test and one short smoke. Record environment and parameters in benchmark-run-card.json. The book validates the card fields and does not freeze the short-run score into prose.

Experiment acceptance card

Review

• A specific hot-path question selects the fixture.
• Smoke proves executability, not capacity.
• A result binds environment, parameters, unit, raw JSON, and revision.
• Production capacity needs independent end-to-end load and fault tests.

Next

Chapter 23 starts Arc 6 with a real TCP port and Redis client to observe DSM replication, repair, and protocol boundaries as E4 evidence.

Evidence links

• BenchmarkMain
• BenchmarkHarnessTest
• RegisterGetLatency
• SecureEnvelopeEncryptionOverhead