AWS SnapStart - Part 13 Measuring warm starts with Java 21 using different Lambda memory settings

Introduction

In the part 12 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 with different memory settings.

In this article we'll also provide measurements for the warm execution times for this use case, as using different Lambda memory settings not only affect the cold start times but also the warm execution times and Lambda costs.

Measuring warm starts with Java 21 with and without SnapStart enabled using different Lambda memory settings.

In our experiment we'll re-use the application introduced in part 9 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 GetProductByIdWithPureJava21Lambda can be used with and without SnapStart and the second one GetProductByIdWithPureJava21LambdaAndPriming uses SnapStart and DynamoDB request invocation priming. We'll measure cold and warm starts using the following memory settings in MBs : 256, 512, 768, 1024, 1536 and 2048.
I also put the cold starts measured in the part 12 into the tables to see both cold and warm starts in one place. The results of the experiment below were based on reproducing more than 100 cold and approximately 100.000 warm starts for the duration of our experiment which ran for approximately 1 hour. Here is the code for the sample application. For it (and experiments from my previous article) I used the load test tool hey, but you can use whatever tool you want, like Serverless-artillery or Postman. Abbreviation c is for the cold start and w is for the warm start.

Cold (c) and warm (w) start times without SnapStart in ms:

Let's put this data into graph, but skip the max value (it's to high so it's difficult to see p50 and p75 values) :

Cold (c) and warm (w) start times with SnapStart without Priming in ms:

Let's put this data into graph, but skip the max value:

Cold (c) and warm (w) start times with SnapStart and with DynamoDB invocation Priming in ms:

Let's put this data into graph, but skip the max value:

Conclusions

In this article we measured the warm start time of the Lambda function without SnapStart with SnapStart and for the latter with additional priming of DynamoDB invocation using different Lambda memory settings.

In case of not enabling SnapStart for the Lambda function we observed that increasing memory reduces the warm execution time for our use case especially for p>90. As adding more memory to the Lambda function is also a cost factor, the sweet spot between cold and warm start time and cost is somewhere between 768 and 1204 MB memory setting for the Lambda function for our use case. You can use AWS Lambda Power Tuning for very nice visualisations.

We made similar observations in the case of enabling SnapStart for the Lambda function without and with additionally using priming of DynamoDB invocation request. The sweet spot between cold and warm start time and cost is somewhere between 768 and 1024 MB memory setting for the Lambda function for our use case as well. In case of no priming usage, we also see some improvements in maximal values for the warm execution by adding more memory than 1024 MB.

In case of applying priming of the DynamoDB invocation there is only little to no improvements of the cold and warm execution times using more than 1024 MB memory even for p99, p99.9 and maximal values.

In the next articles we'll also provide measurements for the cold and warm execution times for the same sample application using different memory settings but for Java 17 and we'll compare the measurements between Java 21 and 17 runtimes. Stay tuned!