Introduction
In part 9 of our series, we measured the cold starts of the Lambda function with Corretto Java 21 runtime without SnapStart enabled, with SnapStart enabled, and also applied DynamoDB invocation priming optimization. Lambda functions had 1024MB of memory, and the deployment artifact size (jar file) is approx. 15MB. In this article, we will make the same measurements but play around with different deployment artifact sizes to figure out whether it will make any difference.
Measuring cold starts with Java 21 with and without SnapStart enabled using deployment artifact sizes
Let's consider 3 scenarios:
- 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 so 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 artifact size of such an application is 137 KB only.
- Medium-sized application with DynamoDB persistence. We'll re-use the application introduced in part 9 for this. There are basically 2 Lambda functions that both respond to the API Gateway requests and retrieve the product by id from the DynamoDB received via the API Gateway. One Lambda function can be used with and without SnapStart, and the second one uses SnapStart and DynamoDB request invocation priming. There are a 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 artifact size of such an application is 15 MB.
- Big-sized application with DynamoDB persistence and dependencies to many other AWS services. It's similar to a medium-sized application. There are basically 2 Lambda functions that both respond to the API Gateway requests and retrieve a product by id from the DynamoDB received via the API Gateway. One Lambda function can be used with and without SnapStart, and the second one uses SnapStart and DynamoDB request invocation priming. There are a 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 many other dependencies to various AWS services like SNS, Kinesis, EventBridge, and Bedrock, but we won't even use them in our application. Deployment artifact size (jar file) is 50 MB for this use case.
The results of the experiment below were based on reproducing approximately 100 cold starts, which were generated during the experiment, which ran for approximately 1 hour. All Lambda functions had a 1024 MB memory setting.
Legend: SMALL - corresponds to 137 KB deployment artifact size, MEDIUM to 15 MB, and BIG to 50 MB.
| Experiment description | p50 | p90 | p99 |
|---|---|---|---|
| SMALL: cold start time w/o SnapStart | 547.77 | 595.15 | 618.88 |
| SMALL: cold start time with SnapStart w/o Priming | 483.92 | 663.65 | 774.08 |
| SMALL: cold start time with SnapStart with Priming | 483,92 | 663.65 | 774.08 |
| MEDIUM: cold start time w/o SnapStart | 3155.88 | 3292.80 | 3605.95 |
| MEDIUM: cold start time with SnapStart w/o Priming | 1591.31 | 1823.14 | 2021.67 |
| MEDIUM: cold start time with SnapStart with Priming | 760.79 | 955.76 | 1200.12 |
| BIG: cold start time w/o SnapStart | 3165.20 | 3317.44 | 3666.15 |
| BIG: cold start time with SnapStart w/o Priming | 1608.89 | 2095.23 | 2509.05 |
| BIG: cold start time with SnapStart with Priming | 763.18 | 1373.74 | 1623.76 |
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 in this simple case.
Let's put the figures on the graphs for each percentile to be able to compare the effect of the deployment artifact sizes better.
For p50:
For p90:
For p99:
Conclusions
Some interesting insights are 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 the usage of the SnapStart, but also with! Try to make your Lambda functions small and single-purpose!
In one of the next articles, we'll do the same measurements but for Java 17 runtime, as Java 21 is quite new, and I expect the majority to use Java 17. Stay tuned!
Top comments (0)