main
The access walk's scale check (the access-walk-* suites, kind measure): the benchmark's accounts on the V10 node and one store, in this JVM, as ComponentRun runs them, through the node's public API and the store's own driver.
A first node opens --aggregates accounts and deposits into each until it has --streams streams, then completes its walk of them; the options --seed.<name>=<value> are its alone (--seed.wow.access.walk-share=1: it walks what it seeded unbounded). The store's history then loses its access attributes, as a log an import wrote holds none, except the accounts the deposits go to, and the account's walk record unless --walk=none (the A/A arm: the same history, with its walk recorded as completed, so nothing is walked); the store then settles (a vacuum and a checkpoint), so the measured window pays for neither that rewrite nor the seeding. A second node then starts: its walk stamps the accounts as its wow.access.* options pace it, while --rate deposits a second (E1, open loop, none at 0) run over --measure seconds after --warm-up. --targets says where they go: stamped (the default), the tenth of the accounts the walk reaches last, which keep their attributes, so the walk is the only stamping; first, the first accounts the walk reaches, which keep theirs too, so it stamps what the deposits write; all, every account, none stamped, so the built-in wow.access subscription also stamps the history of each one a deposit reaches first, as it does after a change of the access schema. It writes measure.json to --out: the deposits' latencies, the CPU used over the window, and the walk's progress: how many it stamped over the measured window and at what rate, and how far it got from the second node's start; with --complete=yes, it waits for the walk's completion.
Run it on the install's class path with main class AccessWalkBenchKt; bench.sh's measure command does.
The L1 component benchmark of the benchmark ladder: the benchmark's domain on the V10 kernel and one store, in this JVM, without HTTP or a load generator. It opens --accounts accounts, then sends --ops commands of --scenario (E1 a deposit answered once committed, E3 a transfer answered once the saga's entry is committed, E1-large an annotation of five ~2 KB notes) through the node's CommandClient, --concurrency at a time, after --warm-up-ops unrecorded ones. It counts what each operation costs (the store's round trips by command, the bytes allocated) and times it (throughput and latency of a closed loop, short and indicative: an end-to-end run gives the conclusions), and writes component.json to --out. Counts do not depend on the machine's load, so they can run anywhere (the tiered measurement of); a core-path change attaches at least these counts.
Run it on the install's class path (every jar of its lib) with main class ComponentBenchKt; bench.sh's component command does.