Repository navigation
Add support for CRaC (AWS Snapstart) #1588
Description
Activity
@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 CRaCDescribe 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 metricsHey @subhash686 glad you're interested! I'm no longer a maintainer here, but:
@msailes @dreamorosi @jeromevdl can anyone point @subhash686 in the right direction?
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.
-
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?
- marked Java agent instrumentation and suggest warm-up for slow code #1806 as a duplicate of this issue
on Apr 15, 2025 Another note: When we implement this we should add documentation about https://github.com/aws/aws-lambda-snapstart-java-rules.
SnapStart Bug Scanner is the SpotBugs plugin for helping AWS Lambda customers inspect their functions against potential bugs unique to AWS Lambda SnapStart environment.
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).
Reacted by Vadym KazulkinHi @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.
- changed the title
[-]Add support for CRaC[/-][+]Add support for CRaC (AWS Snapstart)[/+]on Apr 29, 2025 12 remaining items
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.
Reacted by Subhash Kovela- linked a pull request that will close this issuefeat: Support CRaC and priming of powertools metrics and idempotency-dynamodb #1861
on Jul 31, 2025 - added sub-issues
on 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).
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