AWS SnapStart - Part 18 Measuring cold starts with Java 17 using different deployment artifact sizes

Introduction

In the part 8 of our series we measured the cold start of the Lambda function with Corretto Java 17 runtime without SnapStart enabled, with SnapStart enabled and also applied DynamoDB invocation priming optimization. Lambda functions had 1024 MB memory and the deployment package (jar file) was approx. 15 MB. In this article we will make the same measurements but play around deployment package size to figure out whether it will make a difference similar as we did in the article Measuring cold starts with Java 21 using different deployment artifact sizes but now using Java 17.

Measuring cold starts with Java 17 with and without SnapStart enabled using deployment artifact sizes

Lets's consider the same 3 scenarios for Java 17 (as we did for Java 21):

1. Small HelloWorld-style application which consists of Lambda receiving the API Gateway request with product id and basically prints this id out. There is no persistence layer involved. The application is that simple, that there is no priming technique to be applied. There are only several dependencies declared in pom.xml like aws-lambda-java-core and slf4j-simple. The deployment size of such an application is 137 KB only.
2. Medium Size application with DynamoDB persistence. We'll re-use the application introduced in part 8 for this. There are basically 2 Lambda functions which both respond to the API Gateway requests and retrieve product by id received from the API Gateway from DynamoDB. One Lambda function can be used with and without SnapStart and the second one uses SnapStart and DynamoDB request invocation priming. There are bunch of dependencies declared in pom.xml like aws-lambda-java-core, aws-lambda-java-events, slf4j-simple, crac, dynamodb and url-connection-client. The deployment size of such application is 15 MB.
3. Big Size application with DynamoDB persistence and dependencies to many other AWS services. It's similira to medium size application. There are basically 2 Lambda functions which both respond to the APIGateway requests and retrieve product by id received from the API Gateway from DynamoDB. One Lambda function can be used with and without SnapStart and the second one uses SnapStart and DynamoDB request invocation priming. There are bunch of dependencies declared in pom.xml like aws-lambda-java-core, aws-lambda-java-events, slf4j-simple, crac, dynamodb and url-connection-client. But we also declare man other dependencies to various differnt AWS service like sns, kinesis, eventbridge, bedrock, but we won't even use them in our application. So such declaration makes only the package size bigger is then 50 MB.

The results of the experiment below were based on reproducing approximately 100 cold starts, which were reproduced during the experiment which ran for approximately 1 hour. All Lambda functions had 1024 MB memory setting.

Legend: SMALL - corresponds to 137 KB deployment artifact size, MEDIUM to 15 MB and BIG to 50 MB.

For the small deployment artifact size cold start time with SnapStart enabled and with and without Priming are the same because there is nothing to prime is this simple case.

Conclusions

There are some interesting insights coming from those measurements aso concerning the usage of SnapStart itself: for the small deployment size there is no real benefit of using SnapStart as cold start times with and without it are quite comparable. But applications and Lambda functions without any real dependencies incuding those to other AWS services are quite exceptional.

There is also quite noticable cold start difference for p90 and p99 comparing medium and big deployment artifact sizes whereas p50 remained similar. And of course cold starts for medium and big deployment sizes are much bigger than with the small one. So also for Java 21 the deployment size still plays a crucial role for the cold start without usage of the SnapStart but also with! Try to make your Lambda functions small and single-purposed!

Comparing these measurements with the same measurements done for Java 21 we observe a bit lower cold start times for Java 17 in case SnapStart is not being enabled for all 3 package sizes for our use case. In case SnapStart is enabled the results are much closer for both with and without priming.