|30 minutes||Review the Performance Demo|
- Reference: (deprecated) Measurement of RChain Network Performance
CORE-937Getting issue details...
- Contract dupe(5) is okay. We need to fine tune the memory size of the containers.
- Measuring deploys → we should measure it internally. Ethereum users will be interested in the number of deploys.
- After a successful deploy, the user won't get results back until the block is proposed. Once the block is proposed, the user will see their transaction within a block.
- This is a measure of transaction latency
- We need to manage stakeholder expectations around the issue of latency and finalization
- DECISION - not to include in the deploy demo for test net, and be able to speak to when the question comes up at the conference
- Contract deployments (#3 on (deprecated) Measurement of RChain Network Performance)
- Description of the process:
- Deploy a set of contracts with names, so that they can be called in a subsequent deploy.
- Obtain the address for each contract deployed on the blockchain.
- Then run a series of transactions that reference the name of that contract.
- Is this the same as #1 on (deprecated) Measurement of RChain Network Performance?
- Not really although they could be done in the same demo (Mike)
- Still worth testing separately (Mike and Michael B)
- Although the performance numbers should be identical (Michael B)
- It's the overhead in looking up the contract should be nil, but there may be ms difference (Mike)
- NEEDED the contract for this test so the test is something that is distinct from #4
- Demo script (and cast)
- Walkthrough of the performance test harness (Łukasz and Dom)
Walkthrough of what Grafana shows (Łukasz and Dom)
- Show a high number of comm event using dupe
- Steps in the Demo:Demo #3 and 4 - contract deployments and token transactions (Michael Birch and Medha)
- Set up the demo
- Execute the performance testGoals
- Review the results
- Describe the contracts we ran & the tooling
- Q & A