Introduction
In the article series Spring Boot 3 application on AWS Lambda we already introduced how to develop the application using Lambda Custom Runtime with GraalVM Native Image based in the part 12. The sample application was based on Spring Cloud Function AWS and used Spring Boot 3.2. In the part 13 we also measured the performance (cold and warm start times ) of the Lambda function using this approach.
Not it's time to use the upgraded version of our application introduced in the article Spring Boot 3.4 application on AWS Lambda- Part 1 AWS Serverless Java Container and deploy it using Lambda Custom Runtime based on GraalVM Native Image, in a similar way as we did in the previous article for the GraalVM Native Image with Spring Cloud Function AWS.
How to write AWS Lambda function with Lambda Custom Runtime with GraalVM Native Image based on AWS Serverless Java Container and Spring Boot 3.4
The steps to change the existing application with Java Corretto 21 runtime to be deployed as Lambda Custom Runtime with GraalVM Native Image introduced in the article Spring Boot 3 application on AWS Lambda - Part 12 Develop application with GraalVM Native Image remain completely the same.
The sample simple application also remains the same, see the architecture below:
But I updated the application introduced in the article Spring Boot 3.4 application on AWS Lambda- Part 1 AWS Serverless Java Container to use Lambda Custom Runtime based on GraalVM Native Image and published the source code in the spring-boot-3.4-with-aws-serverless-java-container-as-graalvm-native-image repository. I used GraalVM version 23.0.1 for it. Of course, since then other minor or major updates of the libraries have been released, but I assume that no other changes besides the version updates in the pom.xml are required to make the applications work.
Following needs to be installed in order to build and deploy the sample application:
- Java 21, for example Amazon Corretto 21
- Apache Maven
- AWS CLI
- AWS SAM
- GraalVM, for example GraalVM 23.0.1
- Native Image
In order to build the application, execute mvn clean package -P native.
In order to create the product with id equal to 1, execute
curl -m PUT -d '{ "id": 1, "name": "Print 10x13", "price": 0.15 }' -H "X-API-Key: a6ZbcDefQW12BN56WEX34" https://{$API_GATEWAY_URL}/prod/products
In order to retrieve the product with id equal to 1, execute
curl -H "X-API-Key: a6ZbcDefQW12BN56WEX34" https://{$API_GATEWAY_URL}/prod/products/1
Measuring cold and warm start time of the AWS Lambda function with Lambda Custom Runtime with GraalVM Native Image based on AWS Serverless Java Container and Spring Boot 3.4
All techniques to measure AWS Lambda performance introduced in the part 13 are also still valid. Lambda SnapStart can't be enabled for the Lambda Custom Runtime as of now.
The results of the experiment below were as well based on reproducing more than 100 cold and approximately 100.000 warm starts with Lambda function GetProductByIdFunction with 1024 MB memory setting for the duration of 1 hour. For it I used the load test tool hey, but you can use whatever tool you want, like Serverless-artillery or Postman.
So let's provide the results of the measurement. Abbreviation c stays for the cold start and w is for the warm start.
Cold (c) and warm (w) start time in ms:
| c p50 | c p75 | c p90 | c p99 | c p99.9 | c max | w p50 | w p75 | w p90 | w p99 | w p99.9 | w max |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 883.25 | 890.34 | 907.41 | 935.03 | 937.84 | 937.93 | 5.73 | 6.20 | 6.72 | 10.83 | 66.63 | 151.62 |
Conclusion
In this article, we updated our sample application introduced in the article Spring Boot 3.4 application on AWS Lambda- Part 1 AWS Serverless Java Container and deployed it as Lambda Custom Runtime based on GraalVM Native Image.
Compared to the Lambda performance measurements for the Spring Boot 3.4 application on AWS Lambda- GraalVM Native Image with Spring Cloud Function AWS we observe slightly reduced cold start times with GraalVM Native Image based on AWS Serverless Java Container and comparable warm start times between both.
Compared to the Lambda performance measurements for Lambda function with GraalVM Native Image - Part 5 Measuring cold and warm starts with GraalVM 23 which we did using pure Java Lambda function without any frameworks like Spring Boot we still observe the same : significantly reduced cold start times (up to 300 ms) and slightly reduced warm start times for the pure Lambda function. So the usage of the Spring Boot on top of it does decrease Lambda performance, but of course increases developer's productivity by providing abstractions and additional features.
It's worth investigating which not required dependencies can be excluded in the pom.xml to the deployment artifact size and therefore further potentially reduce the cold start times, see some thoughts about it already described in the article Spring Boot 3.4 application on AWS Lambda- Part 1 AWS Serverless Java Container.
If you have read my article(s) and liked its content, please support me by following me on my GitHub account and giving my repos a star.
Top comments (0)