We don’t have any functions for that. You can use the --with-cycles
flag when deploying and only adding a few cycles so it’ll run out sometime soon. It takes a few minutes of fiddling until you find the right amount, but it should work for some crude testing.
1 Like
You could call_with_cycles() another canister and “drain” your test canister this way.
3 Likes
What about the rest of benchmarking? Is it similar in a local environment vs mainnet? For example:
- does the local artificial consensus delay (i.e. an update call vs a query call) include a simulation of network effects that mainnet nodes would have?
- in mainnet, there is a limit for the length of the incoming messages queue, and ingress messages maybe be rejected/ignored. Is there a similar limit on the local environment?
- does the local artificial consensus delay (i.e. an update call vs a query call) include a simulation of network effects that mainnet nodes would have?
- in mainnet, there is a limit for the length of the incoming messages queue, and ingress messages maybe be rejected/ignored. Is there a similar limit on the local environment?
I didn’t test it, but the consensus parameters and the message limits should be the same as on the mainnet.
1 Like
I just ran out of cycles in local deployment for the first time and arrived here. Using dfx 0.11.2, the command to top these up is now coming from the ledger command instead of canister:
dfx ledger fabricate-cycles --all
2 Likes