-
Notifications
You must be signed in to change notification settings - Fork 14
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
42b7fe7
commit 5532af8
Showing
17 changed files
with
2,291 additions
and
0 deletions.
There are no files selected for viewing
242 changes: 242 additions & 0 deletions
242
utils/e2e-tests/bash/fixtures/help.benchmark.block.stdout.txt
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,242 @@ | ||
Benchmark the execution time of historic blocks. | ||
|
||
This can be used to verify that blocks do not use more weight than they consumed in their `WeightInfo`. Example: | ||
|
||
Let's say you are on a Substrate chain and want to verify that the first 3 blocks did not use more weight than declared which would otherwise be an issue. To test this with a dev node, first create one with a temp directory: | ||
|
||
$ substrate --dev -d /tmp/my-dev --execution wasm --wasm-execution compiled | ||
|
||
And wait some time to let it produce 3 blocks. Then benchmark them with: | ||
|
||
$ substrate benchmark-block --from 1 --to 3 --dev -d /tmp/my-dev --execution wasm --wasm-execution compiled --pruning archive | ||
|
||
The output will be similar to this: | ||
|
||
Block 1 with 1 tx used 77.34% of its weight ( 5,308,964 of 6,864,645 ns) Block 2 with 1 tx used 77.99% of its weight ( 5,353,992 of 6,864,645 ns) Block 3 with 1 tx used 75.91% of its weight ( 5,305,938 of 6,989,645 ns) | ||
|
||
The percent number is important and indicates how much weight was used as compared to the consumed weight. This number should be below 100% for reference hardware. | ||
|
||
Usage: humanode-peer benchmark block [OPTIONS] --from <FROM> --to <TO> | ||
|
||
Options: | ||
--chain <CHAIN_SPEC> | ||
Specify the chain specification. | ||
|
||
It can be one of the predefined ones (dev, local, or staging) or it can be a path to a file with the chainspec (such as one exported by the `build-spec` subcommand). | ||
|
||
--dev | ||
Specify the development chain. | ||
|
||
This flag sets `--chain=dev`, `--force-authoring`, `--rpc-cors=all`, `--alice`, and `--tmp` flags, unless explicitly overridden. | ||
|
||
-d, --base-path <PATH> | ||
Specify custom base path | ||
|
||
-l, --log <LOG_PATTERN>... | ||
Sets a custom logging filter. Syntax is `<target>=<level>`, e.g. -lsync=debug. | ||
|
||
Log levels (least to most verbose) are error, warn, info, debug, and trace. By default, all targets log `info`. The global log level can be set with `-l<level>`. | ||
|
||
--detailed-log-output | ||
Enable detailed log output. | ||
|
||
This includes displaying the log target, log level and thread name. | ||
|
||
This is automatically enabled when something is logged with any higher level than `info`. | ||
|
||
--disable-log-color | ||
Disable log color output | ||
|
||
--enable-log-reloading | ||
Enable feature to dynamically update and reload the log filter. | ||
|
||
Be aware that enabling this feature can lead to a performance decrease up to factor six or more. Depending on the global logging level the performance decrease changes. | ||
|
||
The `system_addLogFilter` and `system_resetLogFilter` RPCs will have no effect with this option not being set. | ||
|
||
--tracing-targets <TARGETS> | ||
Sets a custom profiling filter. Syntax is the same as for logging: `<target>=<level>` | ||
|
||
--tracing-receiver <RECEIVER> | ||
Receiver to process tracing messages | ||
|
||
[default: log] | ||
|
||
Possible values: | ||
- log: Output the tracing records using the log | ||
|
||
--state-pruning <PRUNING_MODE> | ||
Specify the state pruning mode. | ||
|
||
This mode specifies when the block's state (ie, storage) should be pruned (ie, removed) from the database. | ||
|
||
This setting can only be set on the first creation of the database. Every subsequent run will load the pruning mode from the database and will error if the stored mode doesn't match this CLI value. It is fine to drop this CLI flag for subsequent runs. | ||
|
||
Possible values: | ||
|
||
- archive: | ||
|
||
Keep the state of all blocks. | ||
|
||
- 'archive-canonical' | ||
|
||
Keep only the state of finalized blocks. | ||
|
||
- number | ||
|
||
Keep the state of the last number of finalized blocks. | ||
|
||
[default: 256] | ||
|
||
--blocks-pruning <PRUNING_MODE> | ||
Specify the blocks pruning mode. | ||
|
||
This mode specifies when the block's body (including justifications) should be pruned (ie, removed) from the database. | ||
|
||
Possible values: - 'archive' | ||
|
||
Keep all blocks. | ||
|
||
- 'archive-canonical' | ||
|
||
Keep only finalized blocks. | ||
|
||
- number | ||
|
||
Keep the last `number` of finalized blocks. | ||
|
||
[default: archive-canonical] | ||
|
||
--database <DB> | ||
Select database backend to use | ||
|
||
Possible values: | ||
- rocksdb: Facebooks RocksDB | ||
- paritydb: ParityDb. <https://github.com/paritytech/parity-db/> | ||
- auto: Detect whether there is an existing database. Use it, if there is, if not, create new instance of ParityDb | ||
- paritydb-experimental: ParityDb. <https://github.com/paritytech/parity-db/> | ||
|
||
--db-cache <MiB> | ||
Limit the memory the database cache can use | ||
|
||
--wasm-execution <METHOD> | ||
Method for executing Wasm runtime code | ||
|
||
[default: compiled] | ||
|
||
Possible values: | ||
- interpreted-i-know-what-i-do: Uses an interpreter | ||
- compiled: Uses a compiled runtime | ||
|
||
--wasmtime-instantiation-strategy <STRATEGY> | ||
The WASM instantiation method to use. | ||
|
||
Only has an effect when `wasm-execution` is set to `compiled`. | ||
|
||
The copy-on-write strategies are only supported on Linux. If the copy-on-write variant of a strategy is unsupported the executor will fall back to the non-CoW equivalent. | ||
|
||
The fastest (and the default) strategy available is `pooling-copy-on-write`. | ||
|
||
The `legacy-instance-reuse` strategy is deprecated and will be removed in the future. It should only be used in case of issues with the default instantiation strategy. | ||
|
||
[default: pooling-copy-on-write] | ||
|
||
Possible values: | ||
- pooling-copy-on-write: Pool the instances to avoid initializing everything from scratch on each instantiation. Use copy-on-write memory when possible | ||
- recreate-instance-copy-on-write: Recreate the instance from scratch on every instantiation. Use copy-on-write memory when possible | ||
- pooling: Pool the instances to avoid initializing everything from scratch on each instantiation | ||
- recreate-instance: Recreate the instance from scratch on every instantiation. Very slow | ||
- legacy-instance-reuse: Legacy instance reuse mechanism. DEPRECATED. Will be removed in the future | ||
|
||
--wasm-runtime-overrides <PATH> | ||
Specify the path where local WASM runtimes are stored. | ||
|
||
These runtimes will override on-chain runtimes when the version matches. | ||
|
||
--execution-syncing <STRATEGY> | ||
The means of execution used when calling into the runtime for importing blocks as part of an initial sync | ||
|
||
Possible values: | ||
- native: Execute with native build (if available, WebAssembly otherwise) | ||
- wasm: Only execute with the WebAssembly build | ||
- both: Execute with both native (where available) and WebAssembly builds | ||
- native-else-wasm: Execute with the native build if possible; if it fails, then execute with WebAssembly | ||
|
||
--execution-import-block <STRATEGY> | ||
The means of execution used when calling into the runtime for general block import (including locally authored blocks) | ||
|
||
Possible values: | ||
- native: Execute with native build (if available, WebAssembly otherwise) | ||
- wasm: Only execute with the WebAssembly build | ||
- both: Execute with both native (where available) and WebAssembly builds | ||
- native-else-wasm: Execute with the native build if possible; if it fails, then execute with WebAssembly | ||
|
||
--execution-block-construction <STRATEGY> | ||
The means of execution used when calling into the runtime while constructing blocks | ||
|
||
Possible values: | ||
- native: Execute with native build (if available, WebAssembly otherwise) | ||
- wasm: Only execute with the WebAssembly build | ||
- both: Execute with both native (where available) and WebAssembly builds | ||
- native-else-wasm: Execute with the native build if possible; if it fails, then execute with WebAssembly | ||
|
||
--execution-offchain-worker <STRATEGY> | ||
The means of execution used when calling into the runtime while using an off-chain worker | ||
|
||
Possible values: | ||
- native: Execute with native build (if available, WebAssembly otherwise) | ||
- wasm: Only execute with the WebAssembly build | ||
- both: Execute with both native (where available) and WebAssembly builds | ||
- native-else-wasm: Execute with the native build if possible; if it fails, then execute with WebAssembly | ||
|
||
--execution-other <STRATEGY> | ||
The means of execution used when calling into the runtime while not syncing, importing or constructing blocks | ||
|
||
Possible values: | ||
- native: Execute with native build (if available, WebAssembly otherwise) | ||
- wasm: Only execute with the WebAssembly build | ||
- both: Execute with both native (where available) and WebAssembly builds | ||
- native-else-wasm: Execute with the native build if possible; if it fails, then execute with WebAssembly | ||
|
||
--execution <STRATEGY> | ||
The execution strategy that should be used by all execution contexts | ||
|
||
Possible values: | ||
- native: Execute with native build (if available, WebAssembly otherwise) | ||
- wasm: Only execute with the WebAssembly build | ||
- both: Execute with both native (where available) and WebAssembly builds | ||
- native-else-wasm: Execute with the native build if possible; if it fails, then execute with WebAssembly | ||
|
||
--trie-cache-size <Bytes> | ||
Specify the state cache size. | ||
|
||
Providing `0` will disable the cache. | ||
|
||
[default: 67108864] | ||
|
||
--state-cache-size <STATE_CACHE_SIZE> | ||
DEPRECATED | ||
|
||
Switch to `--trie-cache-size`. | ||
|
||
--from <FROM> | ||
Number of the first block to consider | ||
|
||
--to <TO> | ||
Last block number to consider | ||
|
||
--repeat <REPEAT> | ||
Number of times that the benchmark should be repeated for each block | ||
|
||
[default: 10] | ||
|
||
--enable-trie-cache | ||
Enable the Trie cache. | ||
|
||
This should only be used for performance analysis and not for final results. | ||
|
||
-h, --help | ||
Print help (see a summary with '-h') | ||
|
||
-V, --version | ||
Print version |
Oops, something went wrong.