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.
Sampled once on each node when the epoch's cases have finished,
so it is where memory settles after the work rather than a peak during it.
Taken from the container's cgroup, less inactive page cache. The records also
carry mem_peak_bytes, a high water mark since the container
started, which keeps climbing if something leaks.
Cumulative asset count on the minter and the receiver.