Quarkus 3 application on AWS Lambda- Part 7 Introducing extended API Gateway request event Lambda SnapStart priming

Introduction

In the article AWS SnapStart - Using insights from AWS Lambda Profiler Extension for Java to reduce Lambda cold starts , we introduced the extended priming technique to (fully) prime APIGatewayProxyRequestEvent SnapStart.

I wanted to figure out whether we'll improve Lambda performance (especially reduce Lambda cold start times) by applying this technique (I'll call it extended API Gateway request event priming) to the API Gateway request event priming introduced in the article Quarkus 3 application on AWS Lambda- Reducing Lambda cold starts with SnapStart and API Gateway request event priming.

Sample application with the AWS Lambda SnapStart using extended API Gateway request event priming

The main difference compared to the version of the Lambda SnapStart priming is from the article Quarkus 3 application on AWS Lambda- Reducing Lambda cold starts with SnapStart and API Gateway request event priming is in the beforeCheckpoint method of the AmazonAPIGatewayPrimingResource class.

@Override
public void beforeCheckpoint(org.crac.Context<? extends Resource> context) throws Exception {

APIGatewayProxyRequestEvent requestEvent =
LambdaEventSerializers.serializerFor(APIGatewayProxyRequestEvent.class,
AmazonAPIGatewayPrimingResource.class.getClassLoader())
.fromJson(this.getAwsProxyRequestAsJson());

new QuarkusStreamHandler().handleRequest
(new ByteArrayInputStream(this.convertAwsProxyRequestToJsonBytes(requestEvent)),
new ByteArrayOutputStream(), new MockLambdaContext());
}

As explained in the article AWS SnapStart - Using insights from AWS Lambda Profiler Extension for Java to reduce Lambda cold starts , we additionally prime the following invocation:

APIGatewayProxyRequestEvent requestEvent = LambdaEventSerializers.
serializerFor(APIGatewayProxyRequestEvent.class, AmazonAPIGatewayPrimingResource.class.getClassLoader()).
fromJson(this.getAwsProxyRequestAsJson());

This requires adding additional dependency to the pom.xml

<dependency>
   <groupId>com.amazonaws</groupId>
   <artifactId>aws-lambda-java-serialization</artifactId>
   <version>1.1.5</version>
</dependency>

Measurements of cold and warm start times of our application with Lambda SnapStart and extended API Gateway request event priming

The measurements approach (including considering the tiered low-latency snapshot cache) is exactly the same as described in the article Quarkus 3 application on AWS Lambda- Reducing Lambda cold starts with SnapStart and API Gateway request event priming. I'll provide those results and the extended API Gateway request event priming directly below for the comparison.

During the measurements, I discovered that aws-lambda-java-serialization dependency is already provided by the AWS Lambda Java Runtime Interface Client, so we can set its scope to provided like this :

<dependency>
   <groupId>com.amazonaws</groupId>
   <artifactId>aws-lambda-java-serialization</artifactId>
   <version>1.1.5</version>
   <scope>provided</scope>
</dependency>

With this, we'll reduce the deployment artifact size by 4.5 MBs (which should hopefully reduce the Lambda cold start times). In the measurements below for the "extended API Gateway request event priming applied" I provided the results without setting the scope to provided and with it (see explicit "with provided serialization dependency" in the scenario description).

Cold (c) and warm (w) start time with tiered compilation in ms:

Cold (c) and warm (w) start time with -XX:+TieredCompilation -XX:TieredStopAtLevel=1 compilation in ms:

Conclusion

In this article, we demonstrated that by applying Lambda SnapStart extended API Gateway request event priming (with the additional priming of the LambdaEventSerializers.serializerFor(...) invocation), we've got a slightly lower Lambda cold start times especially with provided aws-lambda-java-serialization dependency compared to the standard API Gateway request event priming.

The warm start times vary slightly depending on the percentile and the measurement method but are close to each other, as maximal values sometimes depend on luck, for example whether garbage collection was running or not.

Generally I would recommend using the SnapStart enabled and extended API Gateway request event priming with aws-lambda-java-serialization dependency to be set to the scope "provided". It requires a bit of additional code to be written but it's worth the Lambda performance gain.