It takes about 0.05 T cycles for 10 minutes.
Is this normal? Is this an issue?
you have to pay for storage, this is why your canister constantly consumes cycles
Just to confirm, even if I upload a static front site that doesn’t consume cycles without consensus, do I still have to pay 7.2T cycles (0.05T x 6 x 24) per day as storage fee?
I found table in document.
7.2 T cycles per day is a lot. Are you sure you measured correctly?
For reference, I installed a small canister on Jan 17, did some queries and updates on it, and it’s been running since then and it only consumed ~100B cycles (0.1T) out of the 4T that the canister starts with…
1 Like
This calculation is refer to:
It takes about 0.05 T cycles for 10 minutes.
Is this normal? Is this an issue?
I thought figure is too much, too.So I asked.
My Tip Jar Canister consumes about 0.5 TC every day because it uses heartbeat. It is very hard for me to imagine anything that doesn’t use heartbeat will be more expensive
3 Likes
Canister size matters, of course.
2 Likes
It is very strange. How many assets do you upload to canister?
Is it possible to show your sourcecode?
1 Like
Thank you for reply.But this is not my case.
It takes about 0.05 T cycles for 10 minutes.
I felt strange, too.But I understood under reply though I don’t know what heartbeat is.
about 0.5 TC every day because it uses heartbeat.
I am sorry if my English confuse you.
Thank you your kindness!
Huh interesting, is heartbeat supposed to be that expensive? Is that a Motoko thing, or do Rust heartbeat canisters incur the same cost?
I think it is because the function has to wake up every second even when there is nothing to do. The invocation cost, however small, will add up. It’ll be costly for every canister to rely on implementing heartbeat themselves. Rather there can be one cronjob service that accepts callback registration and more flexible invocation schedules, then other canisters can use the cronjob instead.
1 Like
Hm… is there any way to optimize that? $0.70 every day in cycle costs is not trivial—probably more expensive than most other things, including storage.
For example, could a canister “subscribe” to only get woken up every 1000 heartbeats instead of every 1 heartbeat (without handling that counter logic itself, which would require getting woken up every 1 heartbeat anyways)?
1 Like
I tend to think encoding such schedules into system API is less flexible. Suppose there is a public canister called “cronjob”, it is able to accept anyone’s schedule and make callbacks. Will it not be enough for your need? It can even be upgraded as demand changes, e.g., schedules based on exponential backoff, etc.
1 Like
Or better, it can call you back with some preset data (think a closure) without you having to remember it. Many benefits can be achieved.
Yeah, it would meet my need.
I think the hard part is figuring out the funding model. Maybe when a client wants to “register” a method to be called every X seconds, it also provides a down payment in cycles?
Basically, it seems like this public heartbeat canister would need to maintain an internal ledger mapping clients to cycles, and if and only if a client has enough cycles does the heartbeat canister call the client’s registered canister+method.
Periodically, clients would need to top up the canister with cycles so that their registered method gets continually called, in addition to the down payment.
Right, that seems to be the hard part. But isn’t it a core promise of the Internet Computer vision to enable such services? Then maybe a useful Cron job canister might be a good way to demonstrate that this vision is realistic 
1 Like
Or just count on public donation to keep cronjob canister alive
2 Likes
is it really intended for heartbeat to be so expensive?
See Is there any way to set up recurring payments with the internet computer? - #12 by skilesare for ideas here. It is unlikely that long term every cansister should implement heartbeat that needs scheduling.