I was about to share that in Juno, I’ve noticed the maximal heap memory is roughly around 1GB; going beyond this leads to upgrade failures. I then started looking for references to the asset canister on the IC website, remembering it was 2GB, and was curious to know what I might have been doing wrong.
Surprisingly, I now see that the dfx asset canister also suggests not exceeding 1GB (source: https://internetcomputer.org/docs/current/references/asset-canister), so I no longer think I’m doing something wrong.
However, I’m curious about why this limitation was changed. Was it empirically observed, or found through testing, or else?
We can come up with scenarios where you run into problems with 2GB, so we recommend 1GB just to be very cautious. I personally think going up to ~1.5GB should be safe, but we didn’t run any precise tests.
Hopefully we’ll soon get to writing a stable memory implementation. Then you should be able to go into the tens of GBs
I would be really curious to hear if anyone ever pushed to ~1.5GB because practically now two devs had trouble upgrading Juno’s satellite with 1+ GB, therefore this thread and me being curious about my own implementation because I don’t seem to do anything particular in my pre/post_upgrades (source) .
Thanks for the answer. If you ever do an experiment please let me know!!!
I actually on purpose decided to stick to heap to deliver the dapps’ assets on the web when I introduced stable memory in Juno. Speed is the top priority on the web, and there might be potential cost overhead when query calls are no longer free. This is just a thought I wanted to share.
Did you happen to do any experiments comparing the response time between heap and stable? Or just stuck with the obviously faster option?
There are so many things I’d like to do, and metrics are definitely one area where I haven’t invested enough time. I’ve mostly stuck to the heap option based on empirical evidence.
That’s completely fair since it’s safe to say that heap is faster. I’m curious how big the difference is though, so hopefully I can get around to doing that myself sooner than later