Plan for Load Testing

[katelynsills]

@warner would like to set up load testing on our testnet, automating some typical actions that a user would take. The important thing is to test things that 1) we think the users will definitely do a lot, and 2) which may affect the system. Testing different code that doesn't fit either 1 or 2 is not the goal here.

Below are some discrete stages for testing:

• [x] 1. A user can hit a faucet contract and receive tokens every minute.

  • [ ] 1A: A user can hit a faucet contract and receive non-fungible tokens every minute. (this should not differ substantially from fungible tokens, but because users will definitely do something like this a lot, I would like to ensure it does not differ substantially.)

• [x] 3. A user can trade tokens back and forth on Multipool Autoswap every minute. (The autoswap instance is long-lived).

• [ ] 4. A user can create a new covered call option every minute (this will create a new ZCF vat and new instance every minute). This should use a non-fungible token as the escrowed asset, just to cover more ground with testing.

Delayed until @katelynsills or @michaelfig has more time but still important:

• [ ] 2. A user can send the tokens they have to another user using their wallet contact list every minute. (This will be widely used and also is a different use case as the transfer does not involve Zoe.)

Bonus: An extra fun load test that will probably show up on-chain but which may break things: create a chain of covered call options, where the covered call option (aka invitation) from the previous contract is used as the escrowed asset in the next contract.

Note: The above testing will start at the Zoe API level only (and look like contract unit tests), and will not try to simulate user actions in the UI, nor the dapp communication with the wallet. Wallet API calls will be made sparingly. So for instance, E(zoe).offer will be called rather than E(wallet).addOffer. Eventually we will want to load test the wallet calls, but the API is not currently mature enough until @katelynsills or @michaelfig has more time.

Helpful starting points:

1. Fungible Faucet Dapp:
   • Contract code. Deploy script to make an installation. Deploy script to make an instance. unit tests that make offers and receive the payouts
   • 1A: Start with the fungible contract in the previous step, but make at least two changes: Add an optional parameter to use MathKind.SET in the call to makeZCFMint and change the value to be minted from 1000 to an array, maybe an array of numbers used as identifiers. Everything else should be similar to the task in step 1.
2. Trade on multipool autoswap:
   • Contract to import, script to make an installation, script to make an instance, example tests that use the Zoe API directly
3. Create covered call instances
   • Contract code, tests using the Zoe API Needs deploy scripts, but those should be similar to the ones used in the above steps.

For later:

2. Send tokens to other users.
   • Use the walletAdmin (E(wallet).getAdminFacet()) to add a contact (addContact) and then send them money. This may only be doable through the wallet UI (dapp-svelte-wallet in agoric-sdk) currently, but needs to be available through the wallet API (see https://github.com/Agoric/agoric-sdk/issues/2121).

[warner]

I've pushed the basic fungible-faucet worker ("task") and the code that initiates a new instance (a "cycle") on a periodic basis (the "loop"). There's code to let you configure the rate over HTTP.

[warner]

We've landed the AMM swap, and also a Treasury loan/redeem cycle.