Measurements of cold and warm start times of our application
In Part 8, we learned how to develop a pure Quarkus REST application and deploy it on AWS Lambda.
For the preparation of my talk about developing Serverless Java REST applications on AWS using frameworks such as Quarkus, I found time to measure the performance of the Lambda function with the different approaches (see below). I refer to my articles where we didn't use the Quarkus REST controllers directly, but the pure AWS Lambda functions, to see how we implemented the SnapStart and priming approaches. They look completely the same when using Quarkus REST controllers.
- No SnapStart. Please read the article Introduction to the sample application and first Lambda performance measurements.
- SnapStart enabled, but no priming applied. Please read the article Reducing Lambda cold starts with Lambda SnapStart.
- SnapStart enabled, and DynamoDB request priming applied. Please read the article Reducing Lambda cold starts with SnapStart and DynamoDB request priming.
- SnapStart enabled, and API Gateway request event priming applied. Please read the article Reducing Lambda cold starts with SnapStart and API Gateway request event priming.
Cold (c) and warm (w) start time with -XX:+TieredCompilation -XX:TieredStopAtLevel=1 compilation in ms:
| Scenario Number | 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 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| No SnapStart enabled | 4586 | 4697 | 4855 | 5073 | 5384 | 5389 | 6.51 | 7.39 | 9.08 | 22.45 | 101.41 | 1747 |
| SnapStart enabled but no priming applied, all | 1979 | 2049 | 2816 | 2916 | 2990 | 2991 | 6.51 | 7.51 | 9.08 | 22.09 | 106.35 | 2134 |
| SnapStart enabled but no priming applied, last 70 | 1953 | 2016 | 2098 | 2278 | 2278 | 2278 | 6.51 | 7.51 | 9.08 | 22.09 | 78.66 | 1673 |
| SnapStart enabled and DynamoDB request priming applied, all | 1017 | 1057 | 2013 | 2041 | 2043 | 2045 | 6.30 | 7.27 | 8.94 | 21.07 | 56.36 | 1273 |
| SnapStart enabled and DynamoDB request priming applied, last 70 | 1017 | 1040 | 1095 | 1177 | 1177 | 1177 | 6.30 | 7.27 | 8.94 | 21.07 | 47.44 | 629 |
| SnapStart enabled and API Gateway request event priming applied, all | 747 | 801 | 1092 | 1258 | 1310 | 1311 | 6.51 | 7.63 | 9.53 | 21.75 | 62.00 | 304 |
| SnapStart enabled and API Gateway request event priming applied, last 70 | 735 | 766 | 841 | 1061 | 1061 | 1061 | 6.51 | 7.63 | 9.34 | 21.75 | 55.48 | 261 |
What we observe is that both cold and warm start times of the sample application using Quarkus REST controllers are generally higher when using the pure AWS Lambda functions. I suspect the reason for it lies in an extra adapter layer used to convert the Lambda request to the REST controller. This adapter uses several extra dependencies, which leads to a much bigger artifact size, which is also one of the factors of the increased cold start times. The advantage of using the REST controller is the ability to more easily migrate the business logic from AWS Lambda to EC2 or Containers.
Top comments (0)