Repository navigation
Add support for CRaC (AWS Snapstart) #1588
Description
Is your feature request related to a problem? Please describe.
We should add support for CRaC priming. This will improve the startup performance of applications using Powertools. @msailes has written a helpful guide here. I think we should do this before v2 is released.
Describe the solution you'd like
Describe alternatives you've considered
Additional context
Activity
subhash686 commentedon Dec 24, 2024
@scottgerring I would like to take a CRaCk at this :)
Given this is an enhancement, should I create any additional documentation before starting? Also what is a potential v2 release date that I can work backwards from?
Describe the solution you'd like
Automatic priming of sub-modules independently helps the run time snapshot only what is required.
Try to create a list of classes at build time before packaging (Need to research this a little, but we can definitely start with a manual step of generating such a list)
Preload the identified classes using CRaC
Describe alternatives you've considered
Manual priming may be simpler but we need to decide good code-paths to hint JIT. These are subjective and need maintenance when things change.
Additional context
@msailes blog and examples from embedded metrics
scottgerring commentedon Jan 14, 2025
Hey @subhash686 glad you're interested! I'm no longer a maintainer here, but:
@msailes @dreamorosi @jeromevdl can anyone point @subhash686 in the right direction?
Vadym79 commentedon Mar 27, 2025
I think SnapStart priming can be done in Powertools for several use cases:
Powertools primes itself automatically. Everything which initialized behind Powertools annotations like @idempotency (for example DynamoDB PersistentStore), @logging @metrics and @Tracing can be primed, otherwise the performance with Powertools is not so great. It's too much effort to do things like this and this each time byourselves.
Implement Powertools Utility methods to prime certain client invocations like DynamoDB one, which I do similar to l this implementation https://github.com/Vadym79/AWSLambdaJavaSnapStart/blob/main/pure-lambda-21/src/main/java/software/amazonaws/example/product/handler/GetProductByIdWithDynamoDBPrimingHandler.java. You can offer generic describeDynamoDBTable method which then fulfills the same goal : talk to DynamoDB via Http Client and do some (de)serialization). But the effort to implement this kind of priming by ourselves is not that big as the DAO method to talk to DynamoDB is anyway already there.
Make it easier to implement SnapStart priming described in my article. Via utility method or somehow by introducing the automated priming chain and help with LambdaEventSerializers.serializerFor priming by identifying all used requestEvent types and priming things for them.
Similar to points 2 and 3, also other AWS projects like AWS Serverless Java Container (for Spring Boot 3) can benefit from SnapStart priming which I implemented here. But it's to much code to write by ourselves. Maybe some utility methods or automations may help as well.
phipag commentedon Mar 27, 2025
Hey @Vadym79, thanks for engaging in the discussion 🎉
I really like these points and thank you for providing these examples and articles.
Regarding the first point, I believe that this is a good starting point to gain "kind of automatic" performance advantages when it comes to priming within Powertools itself.
Hey @subhash686! Sorry for getting back to you so late. I am a maintainer here now. Would you still be interested in working on this? I think we can start with a small proof-of-concept for one submodule. Maybe Idempotency is a good candidate for this. We could "invoke-prime" the DynamoDBPersistence automatically. What do you think?
phipag commentedon Apr 15, 2025
Another note: When we implement this we should add documentation about https://github.com/aws/aws-lambda-snapstart-java-rules.
phipag commentedon Apr 28, 2025
I'm going to take a look at this in the next two weeks as part of our
v2release roadmap item.I will focus on priming of the Powertools utilities themselves (use-case 1 mentioned by @Vadym79).
subhash686 commentedon Apr 28, 2025
Hi @phipag Looks like I missed your comment that was for me. I did some work following the original article, but did not change anything yet per the new guidance. I can certainly take a look at Idempotency Dynamo persistence in the next 2 weeks to meet your timeline as well. Please let me know how I can help. Thanks.
[-]Add support for CRaC[/-][+]Add support for CRaC (AWS Snapstart)[/+]12 remaining items
phipag commentedon Jul 31, 2025
PR #1861 was merged. We will keep this issue open as parent issue. I will soon create sub-issues to apply the priming techniques developed as part of this PR across the different modules in this project.
Thanks again to @subhash686 for this great contribution.
powertools-metrics#1996powertools-idempotency#1997powertools-batch#1998powertools-kafka#1999powertools-large-messages#2000powertools-parameters#2002powertools-logging#2001powertools-serialization#2003powertools-tracing#2004powertools-validation#2005classesloaded.txtfile for automatic priming #2006phipag commentedon Aug 4, 2025
I transformed this issue into a parent issue tracking the progress we make on priming implementation across the project. There are sub-issues for each module plus an additional issue to develop a mechanism to keep the
classesloaded.txtfile up-to-date with future code changes (#2006).