An evaluation on nineteen machines — one sidecar, one coordinator, three signature verifiers, six
validator-committers and a twelve-node YugabyteDB — took the committer from 80,000 to 500,000
transactions per second sustained, and identified where the remaining constraint is.
This issue collects the changes that produced it. Each child is independently reviewable; the
measurement that motivated each one is in its own issue, and the full account with all the evidence,
including the retracted findings, is in docs/cluster-optimization-log.md and
docs/optimization-summary.md.
Children: #784 #772 #791 #785 #786 #787 #788 #789 #790 #797 (itself the parent of the five benchmark
issues).
One change lives outside this repository, so it cannot be linked as a sub-issue:
hyperledger/fabric-x-common#165 — [blkstorage] Do not build tx index information no index will
read. serializeBlock extracts a transaction ID per envelope and builds a txindexInfo and a
locPointer for each, whatever the store is configured to index, and a sidecar that indexes by block
number alone reads none of it. Because the append is one serialized goroutine, that was the pipeline's
ceiling: 22.2 ms of a 22.2 ms per-block budget on a machine at 18% CPU. Append went 22.2 ms → 7.1 ms,
lifting the sidecar's own ceiling from ~451,000 tps.
It pays off only together with #784 — a store still indexing transaction IDs genuinely needs that
information — so the two belong in the same deployment.
Where the constraint ends up: not in the committer. At 500,000 tps every committer stage has headroom
— sidecar 14% CPU, coordinator 21%, verifiers 34%, validator-committer preparer 4 of 96 workers busy —
while the database runs 83% CPU and 88% disk busy. Raising throughput further means writing fewer
bytes per transaction, not tuning the committer.
An evaluation on nineteen machines — one sidecar, one coordinator, three signature verifiers, six
validator-committers and a twelve-node YugabyteDB — took the committer from 80,000 to 500,000
transactions per second sustained, and identified where the remaining constraint is.
This issue collects the changes that produced it. Each child is independently reviewable; the
measurement that motivated each one is in its own issue, and the full account with all the evidence,
including the retracted findings, is in
docs/cluster-optimization-log.mdanddocs/optimization-summary.md.Children: #784 #772 #791 #785 #786 #787 #788 #789 #790 #797 (itself the parent of the five benchmark
issues).
One change lives outside this repository, so it cannot be linked as a sub-issue:
hyperledger/fabric-x-common#165 — [blkstorage] Do not build tx index information no index will
read.
serializeBlockextracts a transaction ID per envelope and builds atxindexInfoand alocPointerfor each, whatever the store is configured to index, and a sidecar that indexes by blocknumber alone reads none of it. Because the append is one serialized goroutine, that was the pipeline's
ceiling: 22.2 ms of a 22.2 ms per-block budget on a machine at 18% CPU. Append went 22.2 ms → 7.1 ms,
lifting the sidecar's own ceiling from ~451,000 tps.
It pays off only together with #784 — a store still indexing transaction IDs genuinely needs that
information — so the two belong in the same deployment.
Where the constraint ends up: not in the committer. At 500,000 tps every committer stage has headroom
— sidecar 14% CPU, coordinator 21%, verifiers 34%, validator-committer preparer 4 of 96 workers busy —
while the database runs 83% CPU and 88% disk busy. Raising throughput further means writing fewer
bytes per transaction, not tuning the committer.