Introduction
In the article Develop web application with Spring Boot 3 and GraalVM Native Image, we explored how to develop and deploy Lambda function with Custom Runtime containing GraalVM Native Image (with GraalVM 22 runtime) created from Spring Cloud Function (and its AWS Adapter) application.
In this article we'll measure cold and warms starts of the Lambda function using this approach.
Measuring cold and warm starts of Lambda function with Custom Runtime containing GraalVM Native Image
For our measurements we'll use our sample application from the part 2 and give all Lambda functions 1024 MB memory.
The results of the experiment below were based on reproducing more than 100 cold and approximately 100.000 warm starts for the duration of 1 hour with Lambda function GetProductByIdWithSpringBoot32GraalVMNative which is mapped to the Lambda handler class which is responsible for retrieving the product (stored in the DynamoDB) by its id. For it I used the load test tool hey, but you can use whatever tool you want, like Serverless-artillery or Postman.
Cold (c) and warm (m) 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 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1051.03 | 1061.58 | 1080.86 | 1119.34 | 1149.45 | 1230.28 | 6.45 | 6.77 | 7.33 | 12.50 | 90.92 | 218.17 |
Conclusion
In this article, we measured cold and warms starts of the Lambda function having 1024 MB of memory using Custom Runtime containing GraalVM Native Image created from Spring Cloud Function application introduced in the article Develop web application with Spring Boot 3 and GraalVM Native Image.
Comparing these performance measurements with those we did for AWS Serverless Java Container, AWS Lambda Web Adapter and Spring Cloud Function we see that using GraalVM Native Image we have the lowest warm start times. The cold start times with GraalVM Native Image are generally lower than measured with all other approaches. The only one expection is the cold start with AWS Web Adapter with SnapStart-enabled Lambda function and additional priming of DynamoDB request with which we measured a slightly lower cold start time.
When we compare cold start times to those measured in the article Measuring cold and warm starts of the pure Lambda function with GraalVM Native Image using different Lambda memory settings where our Lambda function doesn't use any framework like Spring Boot, we see that for Lambda function having the same 1024 MB of memory, values about 0.5-0.6 seconds lower for each percentile when using pure Lambda function. I personally think that my sample Spring Boot 3 application has some optimization potential as I can't explain such a big difference in the cold start times between those. Maybe you as a reader can help me optimize my code as my (maybe naive) expectation is that the use of the Spring Boot 3 framework with AWS Lambda and GraalVM Native image may should to approximately 0.2-0.3 seconds higher cold start times comparing to the usage of the pure Lambda function, but not 0.5-0.6 seconds.
At the time of publishing this article newer versions became available (GraalVM 23 runtime, Spring Boot 3.4 and minor update of Spring Cloud Function library) so you case make the version changes to the pom.xml and re-compile GraalVM Native image following the instructions from the part 2 of the series and re-measure the performance.
In the next article of the series, we'll explore the impact of different Lambda memory settings (from 256 to 1536 MBs) on the cold and warm start times as the memory setting also heavily influences the cost of running the Lambda functions.
Top comments (0)