Introduction

In the previous articles of the series about how to connect to Amazon Aurora Serverless v2 from the Lambda function with Data API and AWS SDK for Java we did basic cold and warm starts measurements, compared cold and warm starts between Data API and JDBC and measured effect with SnapStart with and without priming.

In this part of the series we'll introduce optimization strategies for the cold and warm starts.

Optimization strategies for the cold and warm starts

To find a good balance between cold and warm start times you can try out the optimization techniques introduced below. I have not done any measurements with those using Data API and Amazon Aurora Serverless v2 with PostgreSQL database but with similar scenario using DynamoDB database instead. I'll provide references to my relevant articles.

• Try out different Lambda memory settings. All measurements until now have been performed with 1024 MB memory for the Lambda function. With different memory settings you might become better performance for a justifiable price. See my article Measuring cold and warm starts and deployment time with Java 21 using different Lambda memory settings for explanations measurements with DynamoDB.
• Try out different Java compilation options for the Lambda function. All measurements until now have been performed with the compilation option "-XX:+TieredCompilation -XX:TieredStopAtLevel=1" for the Lambda function. There are more other options that can be provided to the Lambda function using environment variable called JAVA_TOOL_OPTIONS which can have different cold and warm starts trade offs. See my article Measuring cold and warm starts with Java 21 using different compilation options for explanations measurements with DynamoDB.
• Lambda arm64 architecture (which supports SnapStart since July 18, 2024) can provide a good cost-performance trade-off comparing to x86_64. See my article AWS Lambda performance with Java 21: x86 vs arm64 - Initial measurements for some insights.
• Try out different synchronous HTTP clients to establish HTTP connection to the database via Data API. All measurements until now have been performed with the default synchronous HTTP Client which is Apache. There are other options like UrlConnection and AWS CRT HTTP clients which provide different performance trade offs for the cold and warm starts.

This is the example of using AWS CRT HTTP client when creating/building the RdsDataClient. URLConnection client can be set similarly.

RdsDataClient.builder().httpClient(AwsCrtHttpClient.create()).build()

Also don't forget to include the dependency to the HTTP client in use to the pom.xml like this:

     <dependency>
        <groupId>software.amazon.awssdk</groupId>
        <artifactId>aws-crt-client</artifactId>
     </dependency>

See my article Measuring cold and warm starts with Java 21 using different synchronous HTTP clients for explanations, code examples and measurements with DynamoDB.

• Explore whether asynchronous HTTP client for Data API is an option for your use case. The default asynchronous HTTP Client is NettyNio. There is another option AWS CRT async HTTP client which provides different performance trade offs for the cold and warm starts.

This is the example of using asynchronous AWS CRT HTTP client when creating/building the RdsDataAsyncClient (which we need to build in case of using asynchronous HTTP Client).

RdsDataAsyncClient.builder().httpClient(AwsCrtAsyncHttpClient.create()).build()

Also don't forget to incldue the dependency to the HTTP client in use to the pom.xml like this:

     <dependency>
        <groupId>software.amazon.awssdk</groupId>
        <artifactId>aws-crt-client</artifactId>
     </dependency>

In this case we have to use Java asynchronous programming model (which is the discussion topic on its own) and therefore each method invocation on the RDSDataAsyncClient will return Java CompletableFuture object. See my article Measuring cold and warm starts with Java 21 using different asynchronous HTTP clients for explanations, code examples and measurements with DynamoDB.

For all potential optimization strategies you can enable SnapStart on the Lambda function and additionally measure the impact of the DynamoDB invocation priming as described in the previous article Data API meets SnapStart of the series.

Also be aware of the impact of the snapshot tiered cache on the cold starts which I described in my article. As I always provide cold start measurements for the first 100 cold starts after deploying the new version of the Lambda function. With the tiered cache in use, I measured and described that the cold start significantly reduces with more subsequent invocations. After certain amount of invocations it then remains constant for the specific Lambda version.

Conclusion

In this article we provided optimization strategies for the cold and warm starts using Data API for Amazon Aurora Serverless v2 with AWS SDK for Java which you can explore to find out the best performance for your use own case.