Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question - Restoring from check-point #1

Open
andrewluetgers opened this issue Feb 6, 2020 · 1 comment
Open

Question - Restoring from check-point #1

andrewluetgers opened this issue Feb 6, 2020 · 1 comment

Comments

@andrewluetgers
Copy link

Serverless environments keep functions warm for some undefined period of time after the initial cold start. Optimizations take advantage of this time period of punctuated statefulness. For example a database connection can be initiated once and reused, an file can be loaded into memory an re-used vs being loaded for every execution.

Can your technique be used to extend this statefulness beyond this undefined warm period with some kind of check-pointing scheme? It seems it would work well for the file-io example not so much for the database connection.

@andrewluetgers andrewluetgers changed the title Question - Restoration Question - Restoring from check-point Feb 6, 2020
@ostenbom
Copy link
Owner

Interesting, I haven't thought of that kind of checkpoint before. The checkpoints I've been thinking about are more along the lines of sharing libraries between different functions. Aka if both function A and function B use numpy, then only restore to the point where numpy was loaded after A so that loading B is faster.

In general I'd want code loaded into a function container to remain as stateless as possible, since state is expensive, but your idea of having database connections "ready" for functions is interesting!

An added point is that when testing this system I was using a warm time of around a few seconds rather than a few hours.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants