Alexandru Gheorghe
f9f886886b
## Summary Built on top of the tooling and ideas introduced in https://github.com/paritytech/polkadot-sdk/pull/2528, this PR introduces a synthetic benchmark for measuring and assessing the performance characteristics of the approval-voting and approval-distribution subsystems. Currently this allows, us to simulate the behaviours of these systems based on the following dimensions: ``` TestConfiguration: # Test 1 - objective: !ApprovalsTest last_considered_tranche: 89 min_coalesce: 1 max_coalesce: 6 enable_assignments_v2: true send_till_tranche: 60 stop_when_approved: false coalesce_tranche_diff: 12 workdir_prefix: "/tmp" num_no_shows_per_candidate: 0 approval_distribution_expected_tof: 6.0 approval_distribution_cpu_ms: 3.0 approval_voting_cpu_ms: 4.30 n_validators: 500 n_cores: 100 n_included_candidates: 100 min_pov_size: 1120 max_pov_size: 5120 peer_bandwidth: 524288000000 bandwidth: 524288000000 latency: min_latency: secs: 0 nanos: 1000000 max_latency: secs: 0 nanos: 100000000 error: 0 num_blocks: 10 ``` ## The approach 1. We build a real overseer with the real implementations for approval-voting and approval-distribution subsystems. 2. For a given network size, for each validator we pre-computed all potential assignments and approvals it would send, because this a computation heavy operation this will be cached on a file on disk and be re-used if the generation parameters don't change. 3. The messages will be sent accordingly to the configured parameters and those are split into 3 main benchmarking scenarios. ## Benchmarking scenarios ### Best case scenario *approvals_throughput_best_case.yaml* It send to the approval-distribution only the minimum required tranche to gathered the needed_approvals, so that a candidate is approved. ### Behaviour in the presence of no-shows *approvals_no_shows.yaml* It sends the tranche needed to approve a candidate when we have a maximum of *num_no_shows_per_candidate* tranches with no-shows for each candidate. ### Maximum throughput *approvals_throughput.yaml* It sends all the tranches for each block and measures the used CPU and necessary network bandwidth. by the approval-voting and approval-distribution subsystem. ## How to run it ``` cargo run -p polkadot-subsystem-bench --release -- test-sequence --path polkadot/node/subsystem-bench/examples/approvals_throughput.yaml ``` ## Evaluating performance ### Use the real subsystems metrics If you follow the steps in https://github.com/paritytech/polkadot-sdk/tree/master/polkadot/node/subsystem-bench#install-grafana for installing locally prometheus and grafana, all real metrics for the `approval-distribution`, `approval-voting` and overseer are available. E.g: <img width="2149" alt="Screenshot 2023-12-05 at 11 07 46" src="https://github.com/paritytech/polkadot-sdk/assets/49718502/cb8ae2dd-178b-4922-bfa4-dc37e572ed38"> <img width="2551" alt="Screenshot 2023-12-05 at 11 09 42" src="https://github.com/paritytech/polkadot-sdk/assets/49718502/8b4542ba-88b9-46f9-9b70-cc345366081b"> <img width="2154" alt="Screenshot 2023-12-05 at 11 10 15" src="https://github.com/paritytech/polkadot-sdk/assets/49718502/b8874d8d-632e-443a-9840-14ad8e90c54f"> <img width="2535" alt="Screenshot 2023-12-05 at 11 10 52" src="https://github.com/paritytech/polkadot-sdk/assets/49718502/779a439f-fd18-4985-bb80-85d5afad78e2"> ### Profile with pyroscope 1. Setup pyroscope following the steps in https://github.com/paritytech/polkadot-sdk/tree/master/polkadot/node/subsystem-bench#install-pyroscope, then run any of the benchmark scenario with `--profile` as the arguments. 2. Open the pyroscope dashboard in grafana, e.g: <img width="2544" alt="Screenshot 2024-01-09 at 17 09 58" src="https://github.com/paritytech/polkadot-sdk/assets/49718502/58f50c99-a910-4d20-951a-8b16639303d9"> ### Useful logs 1. Network bandwidth requirements: ``` Payload bytes received from peers: 503993 KiB total, 50399 KiB/block Payload bytes sent to peers: 629971 KiB total, 62997 KiB/block ``` 2. Cpu usage by the approval-distribution/approval-voting subsystems. ``` approval-distribution CPU usage 84.061s approval-distribution CPU usage per block 8.406s approval-voting CPU usage 96.532s approval-voting CPU usage per block 9.653s ``` 3. Time passed until a given block is approved ``` Chain selection approved after 3500 ms hash=0x0101010101010101010101010101010101010101010101010101010101010101 Chain selection approved after 4500 ms hash=0x0202020202020202020202020202020202020202020202020202020202020202 ``` ### Using benchmark to quantify improvements from https://github.com/paritytech/polkadot-sdk/pull/1178 + https://github.com/paritytech/polkadot-sdk/pull/1191 Using a versi-node we compare the scenarios where all new optimisations are disabled with a scenarios where tranche0 assignments are sent in a single message and a conservative simulation where the coalescing of approvals gives us just 50% reduction in the number of messages we send. Overall, what we see is a speedup of around 30-40% in the time it takes to process the necessary messages and a 30-40% reduction in the necessary bandwidth. #### Best case scenario comparison(minimum required tranches sent). Unoptimised ``` Number of blocks: 10 Payload bytes received from peers: 53289 KiB total, 5328 KiB/block Payload bytes sent to peers: 52489 KiB total, 5248 KiB/block approval-distribution CPU usage 6.732s approval-distribution CPU usage per block 0.673s approval-voting CPU usage 9.523s approval-voting CPU usage per block 0.952s ``` vs Optimisation enabled ``` Number of blocks: 10 Payload bytes received from peers: 32141 KiB total, 3214 KiB/block Payload bytes sent to peers: 37314 KiB total, 3731 KiB/block approval-distribution CPU usage 4.658s approval-distribution CPU usage per block 0.466s approval-voting CPU usage 6.236s approval-voting CPU usage per block 0.624s ``` #### Worst case all tranches sent, very unlikely happens when sharding breaks. Unoptimised ``` Number of blocks: 10 Payload bytes received from peers: 746393 KiB total, 74639 KiB/block Payload bytes sent to peers: 729151 KiB total, 72915 KiB/block approval-distribution CPU usage 118.681s approval-distribution CPU usage per block 11.868s approval-voting CPU usage 124.118s approval-voting CPU usage per block 12.412s ``` vs optimised ``` Number of blocks: 10 Payload bytes received from peers: 503993 KiB total, 50399 KiB/block Payload bytes sent to peers: 629971 KiB total, 62997 KiB/block approval-distribution CPU usage 84.061s approval-distribution CPU usage per block 8.406s approval-voting CPU usage 96.532s approval-voting CPU usage per block 9.653s ``` ## TODOs [x] Polish implementation. [x] Use what we have so far to evaluate https://github.com/paritytech/polkadot-sdk/pull/1191 before merging. [x] List of features and additional dimensions we want to use for benchmarking. [x] Run benchmark on hardware similar with versi and kusama nodes. [ ] Add benchmark to be run in CI for catching regression in performance. [ ] Rebase on latest changes for network emulation. --------- Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io> Co-authored-by: Andrei Sandu <andrei-mihail@parity.io> Co-authored-by: Andrei Sandu <54316454+sandreim@users.noreply.github.com>
Polkadot
Implementation of a https://polkadot.network node in Rust based on the Substrate framework.
The README provides information about installing the polkadot binary and developing on the codebase. For more specific
guides, like how to run a validator node, see the Polkadot Wiki.
Installation
Using a pre-compiled binary
If you just wish to run a Polkadot node without compiling it yourself, you may either:
- run the latest binary from our releases page (make sure to also
download all the
workerbinaries and put them in the same directory aspolkadot), or - install Polkadot from one of our package repositories.
Debian-based (Debian, Ubuntu)
Currently supports Debian 10 (Buster) and Ubuntu 20.04 (Focal), and derivatives. Run the following
commands as the root user.
# Import the security@parity.io GPG key
gpg --recv-keys --keyserver hkps://keys.mailvelope.com 9D4B2B6EB8F97156D19669A9FF0812D491B96798
gpg --export 9D4B2B6EB8F97156D19669A9FF0812D491B96798 > /usr/share/keyrings/parity.gpg
# Add the Parity repository and update the package index
echo 'deb [signed-by=/usr/share/keyrings/parity.gpg] https://releases.parity.io/deb release main' > /etc/apt/sources.list.d/parity.list
apt update
# Install the `parity-keyring` package - This will ensure the GPG key
# used by APT remains up-to-date
apt install parity-keyring
# Install polkadot
apt install polkadot
Installation from the Debian repository will create a systemd service that can be used to run a
Polkadot node. This is disabled by default, and can be started by running systemctl start polkadot
on demand (use systemctl enable polkadot to make it auto-start after reboot). By default, it will
run as the polkadot user. Command-line flags passed to the binary can be customized by editing
/etc/default/polkadot. This file will not be overwritten on updating Polkadot. You may also just
run the node directly from the command-line.
Building
Since the Polkadot node is based on Substrate, first set up your build environment according to the Substrate installation instructions.
Install via Cargo
Make sure you have the support software installed from the Build from Source section below this section.
If you want to install Polkadot in your PATH, you can do so with:
cargo install --git https://github.com/paritytech/polkadot-sdk --tag <version> polkadot --locked
Build from Source
Build the client by cloning this repository and running the following commands from the root directory of the repo:
git checkout <latest tagged release>
cargo build --release
Note: if you want to move the built polkadot binary somewhere (e.g. into $PATH) you will also
need to move polkadot-execute-worker and polkadot-prepare-worker. You can let cargo do all this
for you by running:
cargo install --path . --locked
Build from Source with Docker
You can also build from source using Parity CI docker image:
git checkout <latest tagged release>
docker run --rm -it -w /shellhere/polkadot \
-v $(pwd):/shellhere/polkadot \
paritytech/ci-linux:production cargo build --release
sudo chown -R $(id -u):$(id -g) target/
If you want to reproduce other steps of CI process you can use the following guide.
Networks
This repo supports runtimes for Polkadot, Kusama, and Westend.
Connect to Polkadot Mainnet
Connect to the global Polkadot Mainnet network by running:
../target/release/polkadot --chain=polkadot
You can see your node on [telemetry] (set a custom name with --name "my custom name").
telemetry: https://telemetry.polkadot.io/#list/Polkadot
Connect to the "Kusama" Canary Network
Connect to the global Kusama canary network by running:
../target/release/polkadot --chain=kusama
You can see your node on [telemetry] (set a custom name with --name "my custom name").
telemetry: https://telemetry.polkadot.io/#list/Kusama
Connect to the Westend Testnet
Connect to the global Westend testnet by running:
../target/release/polkadot --chain=westend
You can see your node on [telemetry] (set a custom name with --name "my custom name").
telemetry: https://telemetry.polkadot.io/#list/Westend
Obtaining DOTs
If you want to do anything on Polkadot, Kusama, or Westend, then you'll need to get an account and some DOT, KSM, or WND tokens, respectively. Follow the instructions on the Wiki to obtain tokens for your testnet of choice.
Hacking on Polkadot
If you'd actually like to hack on Polkadot, you can grab the source code and build it. Ensure you have Rust and the support software installed.
Then, grab the Polkadot source code:
git clone https://github.com/paritytech/polkadot-sdk.git
cd polkadot
Then build the code. You will need to build in release mode (--release) to start a network. Only
use debug mode for development (faster compile times for development and testing).
cargo build
You can run the tests if you like:
cargo test --workspace --profile testnet
# Or run only the tests for specified crated
cargo test -p <crate-name> --profile testnet
You can start a development chain with:
cargo run --bin polkadot -- --dev
Detailed logs may be shown by running the node with the following environment variables set:
RUST_LOG=debug RUST_BACKTRACE=1 cargo run --bin polkadot -- --dev
Development
You can run a simple single-node development "network" on your machine by running:
cargo run --bin polkadot --release -- --dev
You can muck around by heading to https://polkadot.js.org/apps and choose "Local Node" from the Settings menu.
Local Two-node Testnet
If you want to see the multi-node consensus algorithm in action locally, then you can create a local testnet. You'll need two terminals open. In one, run:
polkadot --dev --alice -d /tmp/alice
And in the other, run:
polkadot --dev --bob -d /tmp/bob --bootnodes '/ip4/127.0.0.1/tcp/30333/p2p/ALICE_BOOTNODE_ID_HERE'
Ensure you replace ALICE_BOOTNODE_ID_HERE with the node ID from the output of the first terminal.
Monitoring
Once you set this up you can take a look at the Polkadot Grafana dashboards that we currently maintain.
Using Docker
Shell Completion
Contributing
Contributing Guidelines
Contributor Code of Conduct
License
Polkadot is GPL 3.0 licensed.