DEV Community

Vadym Kazulkin for AWS Community Builders

Posted on ā€¢ Edited on

2

AWS Lambda SnapStart - Part 8 Measuring Java 17 Lambda cold starts

Introduction

In the part 7 of our series we re-measured the cold start of the Lambda function with Corretto Java 11 runtime and SnapStart enabled after AWS fixed the "Restore Duration" time displayed in the CloudWatch (Logs). You can refer to the part 7 to review the results of our measurements. As SnapStart is also supported with Java 17 runtime directly from the beginning I was curious what cold start we will get with Java 17 with SnapStart enabled.

Measuring the cold start times with Java 17 and SnapStart enabled

For measurement purposes I created/copied the sample application and configured Lambda functions to use Java 17 runtime for Lambda and 1024 MB memory .

Now we use the same CloudWatch Logs Insights Query as we used in the part 7 of our series. We also enable SnapStart for both our Lambda functions GetProductByIdWithPureJava17Lambda (without priming) and GetProductByIdWithPureJava17LambdaAndPriming (with priming of DynamoDB invocation) and after approximately 100 cold starts we got the following durations:

Framework p50 p90 p99
cold start time w/o Priming 1513.85 1648.55 1860.34
cold start time with Priming 725.56 829.03 1066.98

Conclusion

For the cold start times measured with Java 11 and Java 17 runtimes with SnapStart enabled and additionally with and without priming of DynamoDB invocation we got very comparable results. For some percentiles Java 17 cold starts were a bit lower, but this may depend on the executed measurements. This was also my expectation before I started these measurements as SnapStart is based on the whole Firecracker microVM snapshot create and restore phases. And the latter phase is occurring during the cold start of the Lambda function and will probably take similar amount of time independent on the Java runtime version used as JVM restore is only a part of the whole microVM restore. In the next article of series Iā€™d like to share some thoughts on how AWS can further improve its offering around reducing cold starts on AWS Lambda with Java Runtime and also developer experience.

Image of Timescale

šŸš€ pgai Vectorizer: SQLAlchemy and LiteLLM Make Vector Search Simple

We built pgai Vectorizer to simplify embedding management for AI applicationsā€”without needing a separate database or complex infrastructure. Since launch, developers have created over 3,000 vectorizers on Timescale Cloud, with many more self-hosted.

Read more ā†’

Top comments (2)

Collapse
 
imflamboyant profile image
Marko Djakovic ā€¢

I'm curious what happens if you give it 2 gigs of memory?

Collapse
 
vkazulkin profile image
Vadym Kazulkin ā€¢

Will test with the different RAM settings (something for another article), but 500 MB and 1GB are the common ones from my experience.

Best Practices for Running  Container WordPress on AWS (ECS, EFS, RDS, ELB) using CDK cover image

Best Practices for Running Container WordPress on AWS (ECS, EFS, RDS, ELB) using CDK

This post discusses the process of migrating a growing WordPress eShop business to AWS using AWS CDK for an easily scalable, high availability architecture. The detailed structure encompasses several pillars: Compute, Storage, Database, Cache, CDN, DNS, Security, and Backup.

Read full post