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

Increase performance with snapstart/crac and client priming #1570

Open
hamburml opened this issue Feb 4, 2025 · 0 comments
Open

Increase performance with snapstart/crac and client priming #1570

hamburml opened this issue Feb 4, 2025 · 0 comments

Comments

@hamburml
Copy link
Contributor

hamburml commented Feb 4, 2025

Hello,

I try to let my lambdas answer faster after a coldstart. I use snapstart for that. When using s3Client or dynamodbClient the lambda needs a bit time (maybe 1 or 2 seconds) before it can use the client.

I was able to let the whole lambda answer in round 200 ms with crac.

@ApplicationScoped
@Startup
public class Somename implements Resource {

    @Inject
    S3Client s3Client;

    @PostConstruct
    void init() {
        Core.getGlobalContext().register(this); // Register for CRaC lifecycle
    }

    void doSth() {

        // code which is used when lambda runs

    }

    @Override
    public void beforeCheckpoint(Context<? extends Resource> context) throws Exception {
        try {
            s3Client.listBuckets();
        } catch (Exception e) {
            log.info("listBuckets: " + e.getMessage());
        }
        log.info("before checkpoint");
    }

    @Override
    public void afterRestore(Context<? extends Resource> context) throws Exception {
        log.info("after restore");
    }
}

I do not care if an exception is thrown because listBuckets is not working when for example policies are not correctly set. I simply want the s3Client to be ready for action when the lambda gets restored via memory snapshot. The quarkus docu mentions client priming https://quarkus.io/guides/aws-lambda-snapstart and has an example for the DynamoDBClient which is build in a static-block. But if I do it like that I do not use the quarkus-specific ClientProducers in the runtime dependency.

Any recommendations how this can be done more elegant or is my approach sufficient enough?

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

1 participant