The Design & Implementation of Sprites · The Fly Blog is a really fun read. One thing I’m left wondering is how you deal with suspending and resuming the VM execution state. I’m guessing Firecracker snapshotting just like with suspending a Fly machine? But doesn’t this then require writing however much memory is being used (so maybe 1 GB or more) to your object storage every time a sprite sleeps and then reading from that every time it wakes? Seems like this would be unacceptably inefficient/slow, so what magic do you use to optimize that?
https://docs.sprites.dev/working-with-sprites/#what-persists-and-what-doesnt answers this question: RAM doesn’t persist across hibernation and wake. Which I think means that service definitions need to be created for processes to restart on wake.
That is fine but then I think that “hibernation and wake” is misleading terminology: isn’t it effectively shutting down and restarting?
And it would be great if someday there was an option for real hibernation, even if there was some additional cost.
There are a bunch of phases. Sprites get memory snapshotted and then restored next time you use them. We keep memory snapshots around for as long as possible. However, these become cold when we upgrade them, or if they sit for weeks and we need to make room for new snapshots.
We have an intermediate warm state that’s effectively just suspending everything in place.
Which I think means that service definitions need to be created for processes to restart on wake.
You definitely want services. Sprites will reboot (because crash, upgrade, cold, etc). Services ensure that they’re running what they need to when they come up. So you can reliably serve web apps from them, for example.
1 Like
Those docs are wrong, btw. We’re correcting them.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.