- Регистрация
- 1 Мар 2015
- Сообщения
- 6,806
- Баллы
- 155
Introduction
In the article of our series 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 AWS application. In the we measured performance (cold and warm starts) of such a Lambda function with 1024 MB of memory.
In this article, we'll measure the performance (cold and warm starts) of the Lambda function using this approach with different memory settings between 256 and 1536 MBs to explore the trade-off between cost and performance.
Measuring cold and warm starts of Lambda function with Custom Runtime containing GraalVM Native Image with different memory settings
We'll re-use exact the same experiment described in the of this article series but with different memory settings between 256 and 1536 MBs.
Here are results of the experiment:
Cold (c) and warm (m) start time in ms:
Conclusion
In this article, measured cold and warms starts of the Lambda function using Custom Runtime containing GraalVM Native Image with GraalVM 21 runtime created from Spring Cloud Function AWS application introduced in the having different memory settings between 256 and 1536 MBs.
We observe similar things as described in the article . Warm start times are very close to each other also with the lower Lambda function memory setting like 256 or 512 MBs where the difference is mainly visible for the high percentiles (>= p90). The cold start times are quite high for 256 and 512 MBs and starting from 768 MBs of memory they decrease only a bit by giving Lambda more memory, but without any noticeable difference for memory greater than 1024 MB. Depending on your performance requirements you can give Lambda less memory than 1024 MBs as we initial gave in the and have a very good price performance trade-off with 768 MB or even a bit less memory.
We also shared the same observations as described in the conclusion of the . When we compare cold start times to those measured in the article (where Lambda function doesn't use any framework like Spring Boot), we see values about 0.5-0.6 seconds lower for each percentile when using pure Lambda function. I personally think that my has some optimization potential as I can't explain such a big difference in the cold start times between those. My (maybe naive) expectation is that the use of the Spring Boot 3 framework with AWS Lambda and GraalVM Native image may only lead to 0.2-0.3 higher cold start times comparing to the usage of the pure Lambda function.
At the time of publishing this article newer versions of frameworks and tools in use became available (GraalVM 23 runtime, Spring Boot 3.4 and version update of Spring Cloud Function library) so you case make the version changes and re-compile GraalVM Native image following the instructions from the part 2 of the series and re-measure the performance. I'll also soon publish the new measurements with these versions and upgrade the example application.
In the article of our series 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 AWS application. In the we measured performance (cold and warm starts) of such a Lambda function with 1024 MB of memory.
In this article, we'll measure the performance (cold and warm starts) of the Lambda function using this approach with different memory settings between 256 and 1536 MBs to explore the trade-off between cost and performance.
Measuring cold and warm starts of Lambda function with Custom Runtime containing GraalVM Native Image with different memory settings
We'll re-use exact the same experiment described in the of this article series but with different memory settings between 256 and 1536 MBs.
Here are results of the experiment:
Cold (c) and warm (m) start time in ms:
| Memory setting | 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 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 256 MB | 1634.84 | 1659.54 | 1691.35 | 1778.03 | 1785.15 | 1785.7 | 6.56 | 6.99 | 7.63 | 18.33 | 372.54 | 857.7 |
| 512 MB | 1244.44 | 1278.48 | 1313.45 | 1414.28 | 1421.36 | 1421.94 | 6.66 | 7.10 | 7.94 | 25.41 | 181.86 | 414.99 |
| 768 MB | 1111.53 | 1126.07 | 1139.66 | 1192.08 | 1202.86 | 1203.07 | 6.58 | 6.93 | 7.48 | 12.46 | 115.18 | 278.91 |
| 1024 MB | 1051.03 | 1061.58 | 1080.86 | 1119.34 | 1149.45 | 1230.28 | 6.45 | 6.77 | 7.33 | 12.50 | 90.92 | 218.17 |
| 1280 MB | 1022.02 | 1035.39 | 1058.41 | 1065.76 | 1104.64 | 1174.79 | 6.58 | 6.96 | 7.54 | 12.37 | 70.77 | 271.13 |
| 1536 MB | 1009.83 | 1029.20 | 1048.41 | 1161.32 | 1116.24 | 1148.24 | 6.66 | 7.04 | 7.75 | 12.08 | 63.03 | 215.62 |
In this article, measured cold and warms starts of the Lambda function using Custom Runtime containing GraalVM Native Image with GraalVM 21 runtime created from Spring Cloud Function AWS application introduced in the having different memory settings between 256 and 1536 MBs.
We observe similar things as described in the article . Warm start times are very close to each other also with the lower Lambda function memory setting like 256 or 512 MBs where the difference is mainly visible for the high percentiles (>= p90). The cold start times are quite high for 256 and 512 MBs and starting from 768 MBs of memory they decrease only a bit by giving Lambda more memory, but without any noticeable difference for memory greater than 1024 MB. Depending on your performance requirements you can give Lambda less memory than 1024 MBs as we initial gave in the and have a very good price performance trade-off with 768 MB or even a bit less memory.
We also shared the same observations as described in the conclusion of the . When we compare cold start times to those measured in the article (where Lambda function doesn't use any framework like Spring Boot), we see values about 0.5-0.6 seconds lower for each percentile when using pure Lambda function. I personally think that my has some optimization potential as I can't explain such a big difference in the cold start times between those. My (maybe naive) expectation is that the use of the Spring Boot 3 framework with AWS Lambda and GraalVM Native image may only lead to 0.2-0.3 higher cold start times comparing to the usage of the pure Lambda function.
At the time of publishing this article newer versions of frameworks and tools in use became available (GraalVM 23 runtime, Spring Boot 3.4 and version update of Spring Cloud Function library) so you case make the version changes and re-compile GraalVM Native image following the instructions from the part 2 of the series and re-measure the performance. I'll also soon publish the new measurements with these versions and upgrade the example application.