[Proposal Champion Request] Application-level performance on Canton - which SIG should this sit under?
grants-discuss0 messages
- Hello everyone,I have been measuring how Canton applications behave under load and I would like to find the right home for it before taking it further.https://github.com/fronow/Canton-Stress-Test
To be clear about scope from the start: this is not protocol, synchronizer or node performance. That is Digital Asset's domain and is already funded work. I mean the layer above - whether a given registry, wallet or settlement app is fast enough, what limits it and what it costs to run.
What came out of it
Two things, both measured against third-party code rather than my own.
The first is that contention turned out to follow a law. A wallet picking input holdings at random mostly does not collide with other people - it collides with holdings it has already spent itself. The failure rate is about half the fraction of the pool consumed over a run:
contention ~= f / 2 where f = holdings spent / pool size
Predictions were fixed before the runs. Across an eightfold range of pool depth it tracked to about two percentage points and raising concurrency fourfold moved it by less than one, so it is a bookkeeping effect, not a concurrency effect. Extended to transfers that gather several inputs it becomes geometric rather than linear, because a transfer fails if any one of its inputs is stale.
And it is avoidable: giving each in-flight submission a distinct input removed contention entirely at every concurrency tried, committed 240 of 240 offered transfers against 208 and cost nothing in latency.
The second thing is that the same harness can price a design decision.
Comparing two independent registries doing the same standard transfer, the settlement model turned out to be the expensive decision and the data model not. A completed propose/accept transfer - both transactions, since the receiver has to accept, comes to 26,220 bytes against 15,689 for a preapproved direct one: about +$0.60 a transfer, 67% more and the gap widens with volume because a pre-approval is created once per receiver while an acceptance is paid every time. The two data models differ by 287 bytes, under 2%, in favour of the richer one. Stakeholder count is priced linearly on top of that.
What I am asking for
Looking through the Development Fund I could not find anything on application performance - no load testing, throughput, latency, contention or capacity sizing. The Developer Hub's tool catalogue has the same gap: 54 tools across nine categories, none of them for performance.
I have written this up as a Development Fund proposal and as an external contributor I need a Tech & Ops Committee champion before it can be filed at all. So I am posting here first rather than filing and having it closed
unread.
Three questions, in the order that matters to me:
1. Is this useful, or am I answering a question nobody is asking? That is a real question, not a rhetorical one. The contention model matters most for parties holding many things — treasuries, venues, registries — and much less for ordinary wallets, which I only learned from someone with production data who told me so.
2. Which SIG owns it? Tokenomics, Token Standards and Daml Tooling all seem arguable and I would rather be steered than pick.
3. Is anyone already doing this? If it overlaps work already underway I would rather contribute to that than run alongside it.
The tool, the workloads and the raw reports behind every number are public and Apache-2.0. If anyone wants a number for their own registry, it takes a DAR and about three minutes.
Kind regardsdfrnw