AWSLambdaJavaSnapStart VS serverless-java-frameworks-samples

In the part 2 of the series we introduced AWS Serverless Java Container and in the part 3 we demonstrated how to write AWS Lambda with AWS Serverless Java Container using Java 21 and Spring Boot 3.2. In this article of the series, we'll measure the cold and warm start time including enabling SnapStart on the Lambda function but also applying various priming techniques like priming the DynamoDB invocation and priming the whole web request. We'll use Spring Boot 3.2 sample application for our measurements, and for all Lambda functions use JAVA_TOOL_OPTIONS: "-XX:+TieredCompilation -XX:TieredStopAtLevel=1" and give them all 1024 MB memory.

In our experiment we'll re-use the application introduced in part 8 for this. Here is the code for the sample application. 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 GetProductByIdWithPureJava17Lambda can be used with and without SnapStart and the second one GetProductByIdWithPureJava17LambdaAndPriming uses SnapStart and DynamoDB request invocation priming. We'll measure cold starts using the following memory settings in MBs : 256, 512, 768, 1024, 1536 and 2048.

For the sake of explanation we'll use our Spring Boot 3.2 sample application and use Java 21 runtime for our Lambda functions.

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.

and others will be a part of a separate project and therefore also used without the usage of the all other AWS Serverless Java Container APIs only for purpose of mocking the API Gateway Request/Response (i.e. for Priming). I've already used them for Priming requests for Quarkus and Micronaut frameworks. Dependency to the AWS Serverless Java Container was included by default for the Micronaut on AWS Lambda SnapStart Priming example and needed to be added explicitly for the Quarkus on AWS Lambda SnapStart Priming example only to implement web request priming. We'll make use of these abstractions in one of our subsequent articles when we'll discuss cold and warm start time improvements for Spring Boot 3 application on AWS Lambda using AWS Lambda SnapStart in conjunction with priming techniques.

Using the asynchronous DynamoDBClient means that we'll be using the asynchronous programming model, so the invocation of getItem will return CompletableFuture and this is the code to retrieve the item itself (for the complete code see)

Let's figure out how to configure the HTTP Client. There are 2 places to do it : pom.xml and DynamoProductDao

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.

Small HelloWorld-style application which consists of Lambda receiving the APIGateway request with product id and basically prints this id out. There is no persistence layer involved. The application is that simple, that there is now priming 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 application is 137 KB only.

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

In the previous 8 parts of our series about AWS Lambda SnapStart we measured the cold starts of Lambda function with Java 11 and 17 runtime first without without and with enabling of SnapStart and also applying various optimization techniques like priming when using SnapStart. You can refer to the cold start times measured with GraalVM Native Image. Current measurements reveal, that the fastest cold start times can be achieved with GraalVM Native Image followed by SnapStart with priming (in case you can apply such optimization for your use case, for example when you’re using DynamoDB as your database of choice), followed by SnapStart without any optimizations. Of course the slowest cold start times you will experience without using GraalVM Native Image and SnapStart. See the summarized measurements in my previous articles of this series or in one of my presentations like this one.

Now the measurements of cold start times (and overall API Gateway end-to-end latency) make complete sense and I assume that AWS made a fix to display the "Restore Duration" and thefore the entire cold start time correctly. Nethertheless these are still quite big cold start times (especially if you can't prime some invocations to reduce them), comparing to other Lambda runtimes like Node.js and Python. Obviously GraalVM Native Image shipped with Lambda Custom Runtime can provide much better results (see Results from GraalVM Native images running in custom runtime) but with different set of trade-offs. Of course in case of using SnapSart, the snapshot restore times can be improved in the future, so I hope that we can further reduce the cold start times with Java by several hundred additional milliseconds.

If we compare these metrics with AWS Lambda with plain Java (and AWS SDK for Java version 2) and Micronaut Framework with SnapStart enbled we'll notice that using the Micronaut Framework the average cold start with Quarkus is quite comparable with the first and better than the latter. If we compile our application with GraalVM Native Image and deploy our Lambda as Custom Runtime (which is beyond the scope if this article), we can further reduce the cold start to between 450 and 550ms, see the measurements for the comparable application.