Membership pallet benchmark
Merge request reports
Activity
changed milestone to %runtime-500
added RN-runtime label
mentioned in merge request !138 (merged)
added 14 commits
-
483ed3da...0bfd3e4d - 13 commits from branch
nodes/rust:master
- a5fc0514 - wip add membership benchmark
-
483ed3da...0bfd3e4d - 13 commits from branch
The membership pallet has two instances:
-
Instance1 with
type CheckCallAllowed = Wot;
andtype MetaData = ();
for Membership -
Instance2 with
type CheckCallAllowed = SmithsSubWot;
andtype MetaData = SmithsMembershipMetaData<opaque::SessionKeysWrapper>;
for SmithsMembership
Several problems arise when trying to write the benchmark:
-
request_membership
is not benchmarkable for Instance1 because https://git.duniter.org/nodes/rust/duniter-v2s/-/blob/master/pallets/duniter-wot/src/lib.rs#L245T::IsSubWot::get()
is alwaysFalse
so there is no way to run this extrinsic with the runtime configured as such, hence to perform a benchmark. - To benchmark the pallet, we need
T::MetaData::default()
(or at least a mean to generate someT::MetaData
for the benchmark) to be able to call the extrinsic using this type. In the case of the Instance2, it must be implemented https://git.duniter.org/nodes/rust/duniter-v2s/-/blob/master/runtime/common/src/entities.rs#L109 forSmithsMembershipMetaData
that seems quite complicated, moreover since they are hardly used in the pallet.
I find 1 particularly confusing regarding the documentation https://git.duniter.org/nodes/rust/duniter-v2s/-/blob/master/docs/api/runtime-calls.md that states:
Main Wot Sub Wot request_membership Automatic Available claim_membership Automatic Available revoke_membership Automatic Available But
request_membership
is the only extrinsic that explicitly checks the type of Wot withT::IsSubWot::get()
; the others can be run successfully even with Instance1 whereT::IsSubWot::get()
isFalse
.Either we can (from better to worse):
- Fix 1 and fix 2 to have a benchmark that can be run on the two instances to produce two
weights.rs
files. - If all the extrinsics except
force_request_membership
are not intended to be used in Main Wot, i.e., with the Instance1, we can fix 2 and use one uniqueweights.rs
for the two instances that will be generated using the Instance2. - Fix 1 and use one unique
weights.rs
for the two instances that will be generated using the Instance1 avoiding to touch 2.
-
Instance1 with
I tried a branch
hugo-membership-benchmark
where I declare the call manually and ignore its output.It crashes the runtime, and we can ignore this with
--no-verify
:./target/release/duniter benchmark pallet --chain=dev --steps=3 --repeat=2 --pallet=common_runtime::membership --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=. --no-verify
Still digging. Thanks for https://substrate.stackexchange.com/questions/8215/benchmark-failing-extrinsics
[edit] I now only check the presence of the event when the call is allowed.
claim_membership / automatic
That's what I understood from the
BaseCallFilter
but I have to check that.Edited by Hugo Trentesaux- Resolved by Benjamin Gallois
added 1 commit
- b72f2423 - add comment warning about hardcoded smith metadata
Looks good to me. The failing cucumber test is only a timeout, it succeeds with a larger timeout:
DUNITER_END2END_TESTS_SPAWN_NODE_TIMEOUT=300 cargo cucumber -i account_creation*
The only annoying thing in my opinion is the hardcoding of Dave key in metadata. I added a comment about this and hope we can remove it soon.
added 20 commits
-
b72f2423...70ac32cd - 15 commits from branch
nodes/rust:master
- 6a69d631 - feat: add pallet membership benchmark
- e3864552 - feat(pallet_membership): add weights info
- 14030b41 - feat(runtimes): use our benchmarks for pallet membership
- e6293136 - add comment warning about hardcoded smith metadata
- 46ec59a4 - fix after rebase
Toggle commit list-
b72f2423...70ac32cd - 15 commits from branch
I rebased on master and fixed conflicts introduced by !148 (merged). This should be ok for merge.
enabled an automatic merge when the pipeline for 46ec59a4 succeeds
mentioned in commit 10170f2a