You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our current suite for the loadtest setup connects to 2 clients and mints batches of collectible assets. Then proceeds to send one asset back and forth multiple times. This is sufficient for monitoring the resource usage during minting/sending, but could be extended to cover more parts of the RPC/codebase.
Proposed Changes
Add normal assets to the mix, with varying supplies and dec_displays.
Send a random amount of a random asset on each send
Pick an asset that is fixed across test runs, which is always picked by clients and is costantly sent back and forth
Having this break-away asset will help us compare its resource footprint to the rest of the "common" assets, plus understand it's impact on the overall system (could eventually burn this asset after N sends or until proof size reaches size X)
For the common assets, we should follow an exponential course instead of a linear one. Currently we mint/send a fixed number of assets per run. We could change this to 1.1*X where X is the number of assets minted in the previous run.
The text was updated successfully, but these errors were encountered:
Description
Our current suite for the loadtest setup connects to 2 clients and mints batches of collectible assets. Then proceeds to send one asset back and forth multiple times. This is sufficient for monitoring the resource usage during minting/sending, but could be extended to cover more parts of the RPC/codebase.
Proposed Changes
The text was updated successfully, but these errors were encountered: