Skip to content

Commit

Permalink
Add rest fixtures
Browse files Browse the repository at this point in the history
  • Loading branch information
dmitrylavrenov committed May 9, 2024
1 parent 42b7fe7 commit 5532af8
Show file tree
Hide file tree
Showing 17 changed files with 2,291 additions and 0 deletions.
242 changes: 242 additions & 0 deletions utils/e2e-tests/bash/fixtures/help.benchmark.block.stdout.txt
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
Loading

0 comments on commit 5532af8

Please sign in to comment.