quarkus

Serverless Quarkus Application Demo

Deployment

Deploy the demo to your AWS account using AWS SAM.

Option 1: Managed Java Runtime (without SnapStart)

mvn clean package
sam deploy -g

SAM will create an output of the API Gateway endpoint URL for future use in our load tests. Make sure the app name used here matches with the STACK_NAME present under load-test/run-load-test.sh

Option 2: Managed Java Runtime (with SnapStart)

mvn clean package
sam deploy -t template.snapstart.yaml -g

SAM will create an output of the API Gateway endpoint URL for future use in our load tests. Make sure the app name used here matches with the STACK_NAME present under load-test/run-load-test-snapstart.sh

The SnapStart version uses techniques called Priming and Class Preloading to optimize Lambda initialization time. You can learn more about SnapStart and Priming here.

For Class Preloading, include the -verbose:class JAVA_TOOL_OPTION JVM argument for the Lambda function in the SAM template and after a function invoke, a list of classes is output in CloudWatch Logs which can be preloaded by specifying them in the resources/META-INF/quarkus-preload-classes.txt file. Refer to the Quarkus AWS Lambda SnapStart guide for details on Class Preloading.

Option 3: GraalVM Native Image with Custom Runtime

mvn clean package -Pnative
sam deploy -t template.native.yaml -g

SAM will create an output of the API Gateway endpoint URL for future use in our load tests. Make sure the app name used here matches with the STACK_NAME present under load-test/run-load-test-native.sh

Load Test

Artillery is used to make 100 requests / second for 10 minutes to our API endpoints. You can run this with the following command under load-test directory:

cd load-test

Managed Java Runtime (without SnapStart)

Before running load tests, make sure you update the stack name in load test bash script

./run-load-test.sh

Managed Java Runtime (with SnapStart)

Before running load tests, make sure you update the stack name in load test bash script

./run-load-test-snapstart.sh

Native Image

Before running load tests, make sure you update the stack name in load test bash script

./run-load-test-native.sh

This is a demanding load test, to change the rate alter the arrivalRate value in load-test.yml.

CloudWatch Logs Insights

Using this CloudWatch Logs Insights, you can analyze the latency of the requests made to the Lambda functions.

The query separates cold starts from other requests and then gives you p50, p90 and p99 percentiles.

Latency for JVM version:

⚠️ Please note that this query is not applicable to SnapStart version.

filter @type="REPORT"
| fields greatest(@initDuration, 0) + @duration as duration, ispresent(@initDuration) as coldStart
| stats count(*) as count, pct(duration, 50) as p50, pct(duration, 90) as p90, pct(duration, 99) as p99, max(duration) as max by coldStart

Latency for SnapStart version: AWS Lambda service logs Restoration time differently compared to cold start times in CloudWatch Logs. For this reason, we need different CloudWatch Logs Insights queries to capture performance metrics for SnapStart functions. Also, it's easier to get cold and warm start performance metrics with two different queries rather than one.

Use the below query to get cold start metrics for with SnapStart Lambda functions:

filter @message like "REPORT"
| filter @message not like "RESTORE_REPORT"
| filter @message like "Restore Duration"
| parse @message "Restore Duration:* ms" as restoreTime
| fields @duration + restoreTime as duration
| stats count(*) as count, pct(duration, 50) as p50, pct(duration, 90) as p90, pct(duration, 99) as p99, max(duration) as max

Use the below query to get warm start metrics for with SnapStart Lambda functions:

filter @message like "REPORT"
| filter @message not like "RESTORE_REPORT"
| filter @message not like "Restore Duration"
| fields @duration as duration
| stats count(*) as count, pct(duration, 50) as p50, pct(duration, 90) as p90, pct(duration, 99) as p99, max(duration) as max

Latency for GraalVM version:

AWS X-Ray Tracing

You can add additional detail to your X-Ray tracing by adding a TracingInterceptor to your AWS SDK clients.

Please note that AWS Lambda SnapStart currently does not support X-ray tracing. For this reason, tracing is disabled for all lambda functions in SnapStart version. Refer to the AWS Documentation for the AWS Regions Lambda SnapStart is available in.

Example cold start trace for JVM (non-SnapStart) version:

Example cold start trace for JVM (SnapStart) version:

Example cold start trace for GraalVM version:

Example warm start trace for JVM version:

Example warm start trace for GraalVM version: