support async init for long initialization lambda functions #53
Conversation
bnusunny
changed the title
| ) -> Result<Response<Body>, Error> { | ||
| // continue checking readiness if async_init is configured and the app is not ready | ||
| if options.async_init && !is_app_ready { | ||
| check_readiness(options).await; |
There was a problem hiding this comment.
this is going to add an extra request to the server in every call in this case, even after the server is ready, isn't it? For example, if the same micro-vm serves two requests, one after the other, both of them check if the server is ready, even when we already know that it's ready after the first one.
It might be better to implement a dedicated Tower service as a handler that can keep that state, so any requests after the first one don't need to check if the server is ready.
There was a problem hiding this comment.
Good catch. I have a simple fix for it.
|
Why ASYNC_INIT is not enabled by default? |
|
Only managed runtimes have the 10 seconds limit. Customs runtimes and OCI images do not have this limit. And it's better to have an explicit opt-in to make sure people understand this is not a default behavior. |
Issue #, if available:
Close #35
Description of changes:
support async init for high cold start lambda functions
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.