...
- Michael Birch (Unlicensed): gist from(deprecated) Measurement of RChain Network Performance needs to be revised.
- Once updated, need the output integrated into the performance harness.
- Stable performance - Dupe(5) contract - updates to the scheduler (CORE-1033) will address.
- What is the hardware configuration we need to recommend? Do we need people focusing on this?
- We know we need at least 4 GB of memory
- How many CPU's?
- Approach - What does it take for a node to hit 1K COMM / second? We send a dupe(3) out 1X /second. Have versions of dupe(3) that write on different channels. - The above is in progress by Medha Parlikar (Unlicensed)
- Create a version of dupe that makes a new name.
Jira Legacy server System JIRA serverId 50130123-f232-3df4-bccb-c16e7d83cd3e key RHOL-645 - How are validators deciding when to propose? Gatling is also making a propose.
- We will need to determine what the interval of propose will be & block size (as a result). We can tune the number of proposes per deploy.
- Create a version of dupe that makes a new name.
...
- Mike to provide an updated wide loop contract.
- Will run dupe against stress-docker
- Have a network ready to do this
- Will run wide against stress-docker
- Have a network ready to do this, with the contract set up.
- Will run token transfer contract against test net
- Will speak to our roadmap for performance
- No silver bullet for performance. It's a lot of little fixes.
- Created a performance harness, will become part of our test criteria.
- Re-engineer appends in RSpace
- Optimize how we store blocks in Casper, presently there is a good amount of duplicated data
- Optimize how we pass blocks around then network
- Optimize our utilization of LMDB
- - Issue is reading something out of the DB, checking for a match, and then putting it back.
- to append, requires that a blob needs to be deserialized, checked for a match and then appended to (no match for a produce)
- Customize write locks for channels that are disjoint.
- Examine the performance of the matcher.
- Examine the performance of block storage.
- Examine the performance of cryptographic functions.
- Optimize how we store blocks in Casper, presently there is a good amount of duplicated data
- Optimize replay (proposing node also replays the block, which is not necessary)
- Optimize how we pass blocks around then network
- Optimize read /write locks and threading in transaction handling code.
- Implement peek in Rholang + RSpace
- Will speak to how long we have been performance testing
- When we are feature complete
- What we have built.
- Question about the token transfer contract code - per Michael Stay (Unlicensed) the code appears correct, not sure what the 0, 11 represent.
- Run the token transfer contract and see how the system performs.
- Run with Kent's PR to observe the Neglected invalid block + bonds cache issue
...