One load epoch runs on a schedule against a regtest network whose state is never wiped. The question is not how fast tapd is on a clean node, but what the same work costs once the asset store, the proof archive and the universe have real volume in them.
Wall clock per case, measured separately. Because state is never reset, an upward slope is the cost of accumulated history rather than run-to-run noise.
uni-tapd and uni2-tapd are federation
peers that both sync every asset, so they hold the same content under the same
load and differ only in storage backend. Every epoch checks that by comparing
their multiverse root hashes, which commit to the whole universe. Both figures come from tapd's own
total_db_size, so they are measured the same way. Postgres carries
a fixed multi-megabyte catalog baseline: read the slope, not the offset.
Marginal cost of one epoch's work on each backend. Flat means the cost per unit of work is holding; a rising line means each epoch is getting more expensive to store than the last.
alice-tapd always mints and bob-tapd
always receives, because the send case requires a single minter. These two run
different backends but do different jobs, so this is a per-role growth curve and
not a backend comparison.
Resident set sampled once after the epoch's cases finish, so it
is where memory settles rather than a peak during the run. The high water mark
is memory.peak from the container's cgroup: it cannot be reset
without root, so it only ever rises, and a mark that keeps climbing epoch after
epoch is the leak signal. Split from the receiver because the two differ by
roughly four times and would flatten each other on a shared scale.
Same measurements on the receiving node, which does no minting and holds far fewer assets.
Size of the live assets.backup file each node
keeps on disk, from
#2277.
One compact entry per confirmed unspent leaf, so the curve tracks wallet
size rather than history. Only the receiver is ever restored from its
file; the minter is shown because its wallet is the one that grows.
Every epoch the receiver has its database and proofs destroyed and is rebuilt from its backup file on the same lnd node. The case fails unless the recovered leaf set matches exactly, compared by asset id, script key and amount rather than by count. Import reads whole blocks back from the chain backend to rehydrate stripped proofs, so this is a measurement of chain rehydration and not of a universe server.
Time each node's background federation sync spent per
epoch, from the cursor-based path added in
#2202.
This is measured passively from the daemon logs because nothing can
trigger it: the manual SyncUniverse RPC runs the older
enumeration path, and only the background federation envoy takes the
cursor route. Enumeration discovery costs one pass over every leaf on
both sides; the cursor asks only what has been added since it last
looked.
Seconds from container restart to the daemon answering, measured at the end of every epoch so the restart cannot affect anything recorded before it. This is what a growing database costs before the node serves anything: migrations, and on sqlite the wal-index rebuild, which reached 1.8s on the previous series where the WAL was never checkpointed.
Cumulative asset count on the minter and the receiver.