Add support for CRaC (AWS Snapstart)

[scottgerring]

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

[subhash686]

@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]

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]

I think SnapStart priming can be done in Powertools for several use cases:

1. 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.

2. 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.

3. 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.

4. 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]

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]

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.

[phipag]

I'm going to take a look at this in the next two weeks as part of our v2 release roadmap item.

I will focus on priming of the Powertools utilities themselves (use-case 1 mentioned by @Vadym79).

[subhash686]

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.

[phipag]

Hey @subhash686, welcome back and awesome that you would like to contribute.

It might be a good idea to start with the idempotency module like you suggested as a proof-of-concept. Based on the context provided by @msailes and @Vadym79 I see two opportunities for the library itself to integrate with Snapstart:

1. Automatic priming (the ClassLoader example from the blog post) -> https://github.com/marksailes/snapstart-priming-guide/
2. Manual priming / invoke priming as mentioned in @Vadym79's articles
   • https://dev.to/aws-heroes/aws-lambda-profiler-extension-for-java-part-2-improving-lambda-performance-with-lambda-snapstart-4p06
   • https://dev.to/aws-builders/measuring-java-11-lambda-cold-starts-with-snapstart-part-5-priming-end-to-end-latency-and-deployment-time-jem
   • @Vadym79 also created a repository with code examples: https://github.com/Vadym79/AWSLambdaJavaSnapStart

Generally, it would be nice if this works automatically without the user to call any library methods / change their code.

---

I think we can combine both approaches but let's start with Option (2) because the manual priming can be done module-by-module. Here are some thoughts / next steps for you @subhash686:

• Implement manual priming for the powertools-idempotency-dynamodb module (for example, invoke prime the DynamoDB client)
• Run a load test against a Lambda function for the following scenarios and measure the latency:
  • Without Snapstart enabled
  • With Snapstart enabled
  • With Snapstart enabled and the code changes for the manual priming
• Create PR with the priming code and the load test results
  • Ideally share some steps on how to reproduce the load test

I am happy to support during the progress @subhash686, for example, when it comes to the load tests and we can iterate together on a PR.

Please make sure to base all your work on the v2 branch of the repository. Do you have any questions? Feel free to ping me anytime.

[phipag]

Yesterday, AWS published a blog article about invoke priming (manual priming) and class priming (automatic priming): https://aws.amazon.com/blogs/compute/optimizing-cold-start-performance-of-aws-lambda-using-advanced-priming-strategies-with-snapstart/

They also provide a GitHub repository with example code: https://github.com/aws-samples/lambda-priming-crac-java-cdk

[subhash686]

@phipag I have added the class priming for powertools-metrics and am continuing to work on adding invoke priming for powertools-idempotency. Wondering what is the best way to load test the former, appreciate your guidance there.

[phipag]

Hey @subhash686, awesome progress. A popular load testing tool is artillery which was also used in the blog post I linked in my previous message.

Looking at the GitHub repository linked at the end of this blog post you might be able to use this as an example (https://github.com/aws-samples/lambda-priming-crac-java-cdk/blob/main/infrastructure/loadtest.yaml).

Essentially, you would deploy a Lambda function with SNAPSTART enabled in your AWS account and run the load test once against a Lambda containing your priming code and then another time removing the priming code you added. The ideal result would be a shorter restore duration of the Lambda containing your priming code.

I am happy to do the load testing for you, I would rather focus on the code and I can run the load testing as a validation step once we are working on a PR.

[phipag]

Hey @subhash686, do you have any updates to share already?

[subhash686]

Hey @subhash686, do you have any updates to share already?

Hi @phipag - Yes, I've added manual priming on Dynamo as well. My commits are waiting internal organization review before I could push those out. I'll nudge the concerned team again and most likely get the PR out this week. Thanks for your patience and prompt support.

[phipag]

Thanks, @subhash686, for your continued engagement. I'll stay tuned for your PR.