spike for load testing Fast USDC

[turadg]

What is the Problem Being Solved?

Fast USDC has performance requirements. We need to gain confidence early in development that the end result will meet them.

Description of the Design

Draft how do we measure throughput at peak and sustained early

Prototype load testing ability

Security Considerations

Scaling Considerations

Test Plan

Upgrade Considerations

[LuqiPan]

Update: @toliaqat has given us the go-ahead for @dckc to pair with @gibson042 to spike on this

[dckc]

not exactly the same scope as this, but overlapping:

• SPIKE: prototype participants in Fast USDC sequence diagram #10254

[dckc]

fe1619a has some notes from an Oct 15 chat w/ @gibson042

We talked about a starting point:

1. Deterministic: How many Fast-USDC customers can we serve within the computron limit of a block?

Connecting this with wall-clock time is notoriously tricky:

• computron limit failed to keep swingset compute time in wall-clock bounds #6857

But one approach is:

2. Hardware-dependent: How does the wall-clock time filled with Fast-USDC work compare to the wall-clock time of another full block without Fast-USDC work? (for example, a block full of PSM or Vaults work).

[dckc]

I discovered that we have some historical data on CCTP usage. I'm inclined to deploy the prototype in #10254 in a running chain and simulate a watcher that acts like the historical usage.

[dckc]

I got the prototype just barely deployed in a running chain... almost connected to a watcher account but not quite.

2024-10-17 17:20 8cdeaac

Meanwhile, the historical data show hardly any transactions closer than 15min to each other, so it's a little un-interesting.

So I'm back to leaning toward measuring computrons.

[dckc]

initial computron performance measurement

• 2024-10-18 22:25 a365328 test(quickSend): initial computron performance measurement

  We're not measuing a particularly relevant workload: this is the
  watcher accepting the invitation (and the contract setting up
  accounts).

  The more performance-relevant workloads are user advance and
  settlement.

$ cd agoric-sdk/packages/boot
$ yarn test test/bootstrapTests/quickSend.test.ts
...
  ✔ accept watcher invitation (1.4s)
    ℹ start metering
    ℹ metered cost (beans) 2371734500n
  ─

  2 tests passed
Done in 118.29s.

So now the scope of the SPIKE does include this issue.

• SPIKE: prototype participants in Fast USDC sequence diagram #10254

[dckc]

pretty close to computron measurement for advance.
challenge: protoMsgMocks lacks an entry for this IBC transfer

wallet agoric1watcher offerStatus {
  id: 'report-2',
  invitationSpec: {
    invitationMakerName: 'ReportCCTPCall',
    previousOffer: 'accept-1',
    source: 'continuing'
  },
  numWantsSatisfied: 1,
  offerArgs: {
    amount: 1234n,
    dest: { chainId: 'osmosis-1', encoding: 'bech32', value: 'osmo1333' },
    nobleFwd: 'noble1301333'
  },
  proposal: {},
  payouts: {}
}
watchPacketPattern onFulfilled makeTagged("match:or", [...])
No match yet. Save the pattern for later.

2024-10-20 00:14 e1b5ee3 test(quickSend): measure advance computrons (WIP)

  ✘ [fail]: watcher: accept, report Rejected promise returned by test
    ℹ start metering
    ℹ metered cost (beans) undefined
    ℹ REJECTED from ava test.serial("watcher: accept, report"): (Error#1)
    ℹ Error#1: unsettled value for kp1546

[dckc]

Advance performance measurement: 60M 28.8M computrons

wallet agoric1watcher offerStatus { id: 'report-2', invitationSpec: { invitationMakerName: 'ReportCCTPCall', previousOffer: 'accept-1', source: 'continuing' }, numWantsSatisfied: 1, offerArgs: { amount: 1_234n, dest: { chainId: 'osmosis-1', encoding: 'bech32', value: 'osmo1333' }, nobleFwd: 'noble1301333' }, payouts: {}, proposal: {}, result: 'advance 1104 uusdc sent to osmo1333' }
  ✔ watcher: accept, report (3.2s)
    ℹ start metering
    ℹ accept cost (Mc) 53.357425
    ℹ advance cost (Mc) 28.804383

2024-10-21 22:10 20f3b71 test: fix computron handling; report Mc

goofy measurement

wallet agoric1watcher offerStatus { id: 'report-2', invitationSpec: { invitationMakerName: 'ReportCCTPCall', previousOffer: 'accept-1', source: 'continuing' }, numWantsSatisfied: 1, offerArgs: { amount: 1_234n, dest: { chainId: 'osmosis-1', encoding: 'bech32', value: 'osmo1333' }, nobleFwd: 'noble1301333' }, payouts: {}, proposal: {}, result: 'advance 1104 uusdc sent to osmo1333' }
  ✔ watcher: accept, report (2.9s)
    ℹ start metering
    ℹ accept cost (beans)  1164257500n
    ℹ advance cost (beans) 5988681600n

2024-10-20 00:14 83eefbf test(quickSend): measure advance computrons

[dckc]

Smart Wallet Performance low-hanging fruit

A slog.svg visualization showed some known inefficiencies. I filed issues for them:

• avoid round trip in smart wallet vstorage / storageNode writes #10307
• combine smart wallet vstorage updates for payouts, numWantsSatisfied #10308

[dckc]

@warner @gibson042 how did we get the computron counts in the Agoric Block Capacity Calculator ?

I'm curious whether the 28.8M number can be compared apples-to-apples.

I didn't use the benchmarkerator. Is that how we got the other numbers?