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

Java snapstart issue #808

Open
ledoux7 opened this issue Dec 4, 2023 · 5 comments
Open

Java snapstart issue #808

ledoux7 opened this issue Dec 4, 2023 · 5 comments

Comments

@ledoux7
Copy link

ledoux7 commented Dec 4, 2023

I don't think the current updating function configuration trick makes it so your tests are actually using snapstart based on the numbers. It possibly takes some time before AWS has made the snapstart feature enabled on newly updated functions

image
@maxday
Copy link
Owner

maxday commented Dec 4, 2023

Interesting! I will test with a sleep to see if that affects the number. Thanks for reporting it @ledoux7

@maxday
Copy link
Owner

maxday commented Dec 7, 2023

I could not reproduce, when you say It possibly takes some time before AWS has made the snapstart feature enabled on newly updated functions, are you referring to the docs or any other official source? Thanks!

@ledoux7
Copy link
Author

ledoux7 commented Dec 7, 2023

I don't have any offical source unfortunately, but from my personal experience with using snapstart (with Kotlin) it only seems to work consistently if we do a fresh deploy from cdk. So changing something like an env variable through the console doesn't trigger the rebuild of the snapshot or something. I haven't dug that deep into it, but thought it only was an issue of time.

Could you maybe add a log line to the init part of the handler to confirm if it is run or not? It should not be run if snapstart is used.

@ledoux7
Copy link
Author

ledoux7 commented Dec 7, 2023

Or the problem might be it does not invoke the correct version, list-versions-by-function seems to be returning the $LATEST tag also. https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/list-versions-by-function.html#description

And I'm not really understanding if this is doing what it should, would not the new versions of the lambda not be deployed by the time you call let arns = lambda_manager.list_versions_by_function(runtime).await?; and you then loop over the first 10 versions of this lambda which also includes the $LATEST tag?

async fn invoke_snapstart<'a>(
    runtime: &Runtime,
    retry: &RetryManager,
    lambda_manager: &LambdaManager<'a>,
) -> Result<(), Error> {
    let arns = lambda_manager.list_versions_by_function(runtime).await?;
    for i in 0..10 {
        info!("snapstart run #: {}", i);
        if let Some(arn) = arns.get(i) {
            info!("arn = {}", arn);
            retry
                .retry_async(|| async {
                    lambda_manager
                        .update_function_configuration(&runtime.function_name())
                        .await
                })
                .await?;
            info!("function updated to ensure cold start");
            thread::sleep(Duration::from_secs(5));
            retry
                .retry_async(|| async { lambda_manager.invoke_function(arn).await })
                .await?;
            info!("function invoked");
        }
    }
    Ok(())
}

A better approach could be to create an alias named SnapStart and then updating what version that points to each time you update the function. And just invoking that alias everytime.

@croconut
Copy link

im gonna second that. put 2 different versions of the same code on the lambda (e.g. version 1 and 2 that you can swap between), set the container concurrency to 1 lambda at a time and use an alias. then, to be completely sure you have started a new container, you can change the version the alias is using and invoke against that alias afterwards.

you'll still want to sleep 5 to ensure your next invoke isn't waiting for the previous container to be killed.

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

3 participants