Total Consumption: 6.05637 trillion cycles per day
Cost:
At the current rate of $1.54 per trillion cycles (per cycles ops), this results in:
Daily cost: $9.33
Monthly cost: $283.32 (30 days per month)
Annual cost: $3,405.45
We would like to understand if this level of consumption and cost is typical or if it suggests potential areas for optimization. Are there any adjustments or improvements we could make to reduce cycle usage and associated costs? Your feedback and suggestions would be greatly appreciated.
I think an SNS that has a lot of proposals / voting / reward distribution is burning more cycles, so would be good to know which SNS you are talk about.
Also not sure if its due to a fee, but 1XDR = 1.30 USD = 1Tcycles so that would give different numbers.
I just checked, and it seems that only two governance canister updates are missing. The numbers are from after our last upgrade.
I’m surprised that the index canister consumes that much in particular, and I wonder if it is due to more people querying it and if there is a way to mitigate it.
it seems likely, though I haven’t confirmed it, that you’re up to date enough to have those changes. It seems that the changes in costs were significant.
I believe some further Index canister improvements are planned, but I don’t have a timeline. We’ll try to get an update on what’s coming up later.
I believe some further Index canister improvements are planned
Indeed, we do have further improvements planned for the ledger suite canisters. At the moment we’re considering different options, since e.g., work on some short-term fixes would be made obsolete by work on some medium-term improvements, so we want to evaluate the options before jumping into anything. The cost of the index (and ledger) canisters mainly come from the fact that the index continuously polls the ledger for new transactions using a timer. Ways we’ve identified for addressing this are:
Have the index query the ledger less frequently. This would have a negative effect on UX, e.g., for wallets.
Improve the efficiency of the used timers. Currently, for each invocation of the timer, a 3x base fee is incurred - one when the timer executes, one for a self-call (to make sure the timer is rescheduled in case of a trap), and one for processing the response. This could potentially be reduced to 2x with a custom implementation, or by adding functionality to the timers CDK library.
Using best-effort messages, have the ledger notify the index whenever there are new transactions available. This could potentially have a large impact on the cost for ledgers with infrequent transactions.
Integration of the index into the ledger and/or archive. With this architecture, there should be no need for polling.
We’re planning to look more closely at the options in the next few weeks, and hopefully roll out some improvements in early 2025.