Package-level declarations

The account. Each command function decides on the state alone; a rejection leaves the account as it was.

Why the account rejects a command.

The account: its owner, the balance it may spend, the amount locked by transfers in flight, and whether frozen.

Attaches notes to the account, one event each: the benchmark's large-payload variant (note ⑥, five events of about 2 KB per command).

One note of Annotate.

Who the benchmark's clients are; outside development the host wants that said in a bean. Anonymous, unless benchmark.access says otherwise: claims makes every request a teller's, a caller with a subject and a role whose claims travel with each command, and policy also holds the accounts to an access policy the teller passes, so the two compare the write path's cost under a policy. dataset makes every request an analyst's, whose claims name the owners it reads, and holds the accounts to a policy that compares each account's owner with them: the access scale check's (bench.sh measure), where a dataset of the accounts' rows reads them by that comparison.

The query bounds of the node's stores, logged every second as bench-query-limits {json}, as the node's health says them (the wow contributor's queries component, which /actuator/health/wow shows an operator): per store, its bound now (limit) and its ceiling, the queries running and queued, and, for a bound that adapts to the store's write pressure, whether the last period pressed (pressure), how often it was lowered (decreases), and the pressure it read. So a run's wow.query.busy answers read against the bound that refused them: a bulkhead at its ceiling, or one the adaptation lowered. The server runs without wow-observability, whose meters say the same at a cost the measurements would carry.

The node's overload and fallback signals, counted and logged once a second (bench-signals {json} at WARN, the level the server logs at), so a benchmark can tell a cliff from plain overload without a metrics stack: the tails' store reads by reason (gap, overflow, idle, start), the refused commands by code (a busy lane or node is wow.command.busy), the timed-out waits by the stage they had reached, the dropped wait signals, the failed forwards and the partitions paused and resumed on a systemic failure. Only with bench.signals.enabled=true, which every V10 run of the CI benchmark sets; otherwise the node has no observer. The counts are cumulative from the start. The eShop soak's nodes run a copy (SoakSignals in :eshop-e2e's soakTest source set); BenchSignalsCopyTest keeps the two in line.

BenchSignals as the node's observer, with bench.signals.enabled=true only.

The component run's counters: a MongoDB CommandListener the mongo profile's client takes (MongoBackend), and a wrapper of the postgres profile's DataSource that counts every statement executed and every commit and rollback. ComponentBench passes it as a source of its own; it is no @Configuration, so the end-to-end server's component scan of this package leaves it out and its store calls go unwrapped (B.O-1).

One component run: the accounts opened, then the warm-up and the measured operations.

The transfer saga's confirmation on the source account: the locked amount has left.

The CPU this JVM (the node and the deposits' client) and the store's container used over the measured window, in cores. The store's comes from its cgroup through docker exec, read only at the window's two ends, so the reading costs the run nothing it measures; null where a reading fails (no Docker, no cgroup v2).

The transfer saga's entry of amount from sourceId on the target account.

Freezes the account: it refuses transfers out and entries in, which drives the saga's compensation.

The mongo profile: the application's MongoClient on spring.mongodb.uri, which selects the MongoDB backend. A bean of its own, not the one the host makes of the property, because it takes the application's driver CommandListeners, which no property can add: none in the server, the round-trip counter in ComponentBench. It is built with the stores' MongoPoolGauge, as an application's own client is, so the stores bound their queries by its pool and read their write pressure from it. The postgres profile needs no bean: the host makes its pool of spring.datasource.*.

Starts a transfer from this account to to: locks amount here; the TransferSaga does the rest.

Counts the store's round trips by command name, from the MongoDB driver's command events or the JDBC calls.

The benchmark's bounded context: one aggregate, the account, and the transfer saga between accounts.

The transfer between two accounts: the source has locked the amount (Prepare); the saga enters it on the target, then confirms it on the source, or unlocks it on the source when the target refused it.

The benchmark's V10 server: the account and the transfer saga on MongoDB (the mongo profile) or PostgreSQL (the postgres profile), its state stream published to Kafka (application.yaml). A node of a cluster takes its ports and node id from the command line (test/benchmarks/README.md).

The transfer saga's compensation on the source account: the target refused, the locked amount comes back.

The samples of the store's waits (WalkStore.waits) and of the node's connection pool over the measured window: how often each wait was seen, and the pool's most connections in use and most callers waiting for one.

The account's walk record, as the log's registry holds it: whether it is completed, and the aggregates walked.

One walk run: the history a first node writes, then the second node's walk under the deposits.

The account's log and its walk record, read and written with the store's own driver, as an operator reads the registry (Rebuild and Replay, "Watching it"): the log collection or table wow_log__transfer__account, the registry wow_log_aggregate.

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.

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.

The node's JDBC pool, read through its HikariCP pool bean: connections in use, callers waiting for one, its size; null for a node without one (MongoDB's driver keeps its pool to itself).

value as JSON: maps, lists, strings, numbers, booleans and nulls.