Add sweat.claim load in Locust

[aborg-dev]

This PR introduces sweat.claim contract necessary for #11107 and uses it to implement sweat::defer_batch and sweat.claim::get_claimable_balance_for_account calls.

I originally intended to use sweat.claim::claim but it requires the balance to be locked for some time to be claimed, so to avoid changing sweat.claim contract, I've used get_claimable_balance_for_account method instead, which does a similar amount of work and can be called unconditionally.

You can run this with:

nearup run localnet --binary-path ../nearcore/target/release/ --num-nodes 1 --num-shards 1 --override
export KEY=~/.near/localnet/node0/validator_key.json
locust -H 127.0.0.1:3030 \
  -f locustfiles/sweat.py \
  --funding-key=$KEY --headless -u 10

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 71.09%. Comparing base (a9ddf9c) to head (bf949cc).

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #11119      +/-   ##
==========================================
- Coverage   71.10%   71.09%   -0.01%     
==========================================
  Files         773      773              
  Lines      154176   154176              
  Branches   154176   154176              
==========================================
- Hits       109625   109615      -10     
- Misses      40100    40110      +10     
  Partials     4451     4451              

Flag	Coverage Δ
backward-compatibility	0.24% <ø> (ø)
db-migration	0.24% <ø> (ø)
genesis-check	1.43% <ø> (ø)
integration-tests	36.89% <ø> (+0.01%)	⬆️
linux	69.52% <ø> (-0.01%)	⬇️
linux-nightly	70.55% <ø> (-0.02%)	⬇️
macos	52.64% <ø> (-1.66%)	⬇️
pytests	1.65% <ø> (ø)
sanity-checks	1.44% <ø> (ø)
unittests	66.74% <ø> (-0.01%)	⬇️
upgradability	0.29% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mooori]

The cost of executing claim resp. get_claimable_balance_for_account depends on state: it increases with the number of accruals stored for account_id. I'm still wrapping my head around nearcore's Locust setup for Sweat, but it seems like running a given locust command twice can result in different numbers of storage accesses as the accounts which receive accruals are chosen randomly. This could make it hard to assess the performance impact of nearcore changes based on this workload.

If this interpretation is correct, should we make the generation of accruals deterministic? For instance by introducing a parameter to set the number of accruals per account. That could be done in a follow-up PR.

[mooori]

Add --sweat-claim-wasm parameter?

[aborg-dev]

Added.

[aborg-dev]

The cost of executing claim resp. get_claimable_balance_for_account depends on state: it increases with the number of accruals stored for account_id. I'm still wrapping my head around nearcore's Locust setup for Sweat, but it seems like running a given locust command twice can result in different numbers of storage accesses as the accounts which receive accruals are chosen randomly. This could make it hard to assess the performance impact of nearcore changes based on this workload.

If this interpretation is correct, should we make the generation of accruals deterministic? For instance by introducing a parameter to set the number of accruals per account. That could be done in a follow-up PR.

Yes, I think that is a very good observation. Here I'm just doing plumbing to enable calling these smart contract methods. We need to do another step where we tune the Locust workload to actually exercise the network in interesting ways - what you suggest makes a lot of sense.