Unbounded blocksize network test #945
Comments
|
Hi, can i work on this ? |
|
@amityadav0 if this is interesting to you, definitely feel free to work on it alongside our efforts 🙂 This is part of our larger roadmap for as close to IRL network test (think 1000 nodes), so a canonical version using some yet to be fully fleshed out testing infrastructure, which will require a lot of collaboration and efforts over the course of a few weeks, is something that we will also be working on. tbc though, that does not mean that you can't if this is an interesting topic to you! If doing so, it might be easier to build that test in however you see fit instead of using the canonical infrastructure, and then perhaps we could compare and contribute after the fact. |
|
Hi, It looks interesting to me. Understood. Earlier i was thinking it could be done without more nodes. I am new to codebase, will learn more about the code and then give it a try |
|
I think it's pretty important that any performance-based testing simulates as close as possible to what we expect the network to be i.e. if we think the network will have 100 validators, 100 full nodes and 1000 light clients. That's what we should be measuring against. |
evan-forbes
added
the
WS: Big Blonks 🔭
## Overview This is a refactor of the celestia-app tests in [test-infra](https://github.com/celestiaorg/test-infra). The refactor focuses on further removing boiler plate and using our existing testing utilities for devUX, but also allows for more elaborate test scenarios and data collection. Testground requires that each node is responsible for intializing, operating, performing tests, and collecting data on itself. To do this this refactor adds a new `Role` interface, where we define specific roles that `Plan`, `Execute`, and `Retro`. The first test case makes use of the interface to define a `Leader` and `Follower`, where we can have the `Leader` generate all the keys, configs, genesis, etc during `Plan` and then publishes that data to all `Followers`, which use their respective configuration to start their node. After execution of the test, each `Role` can run arbitrary `Retro` logic over the data produced or collected during the test run. The first experiment is mean to add as similar environment to mainnet as possible. We will use this as a base control case for an upcoming PR that adds the unbounded blocksize test Please see the [README](https://github.com/celestiaorg/celestia-app/blob/db0fdfd3197238c77e72f59222cfaa3ec6648396/test/testground/README.md) for more info and diagrams closes #2033 blocking celestiaorg/celestia-core#945 ## Checklist - [x] New and updated code has appropriate documentation - [x] New and updated code has new and/or updated testing - [x] Required CI checks are passing - [x] Visual proof for any user facing features like CLI or documentation updates - [x] Linked issues closed with keywords --------- Co-authored-by: CHAMI Rachid <[email protected]> Co-authored-by: Rootul Patel <[email protected]>
## Overview This PR introduces the unbounded block size test that I've been using for the past few months to collect data on testground. I'll be going through this later today and removing any less permanent things that were here. NOTE: this is using core v1.31 instead of 1.32. This allows for selecting which nodes are tracing which data, which is crucial to collect round state data on each node while not overwhelming the influxdb node with everything. I'm not sure what we want to do here. The v1.x release branch has already by updated to the fixed version of core that doesn't have this breaking change. closes celestiaorg/celestia-core#1140 and celestiaorg/celestia-core#945 --------- Co-authored-by: CHAMI Rachid <[email protected]> Co-authored-by: Rootul P <[email protected]>
This PR introduces the unbounded block size test that I've been using for the past few months to collect data on testground. I'll be going through this later today and removing any less permanent things that were here. NOTE: this is using core v1.31 instead of 1.32. This allows for selecting which nodes are tracing which data, which is crucial to collect round state data on each node while not overwhelming the influxdb node with everything. I'm not sure what we want to do here. The v1.x release branch has already by updated to the fixed version of core that doesn't have this breaking change. closes celestiaorg/celestia-core#1140 and celestiaorg/celestia-core#945 --------- Co-authored-by: CHAMI Rachid <[email protected]> Co-authored-by: Rootul P <[email protected]>
per recommendation by @cmwaters, it would be valuable to have a test that would continually increase the block size until bandwidth or compute limitations were hit. Provided that we have suitable metric data collection in place, this would give us a better idea of where the bottlenecks are in the entire stack, along with simply providing us with data on how much headroom we have given some set of resources per node in the network.
The text was updated successfully, but these errors were encountered: