DEV Community

AWS Community Builders profile image Vadym Kazulkin
Vadym Kazulkin for AWS Community Builders

Posted on • Edited on

Data API for Amazon Aurora Serverless v2 with AWS SDK for Java - Part 8 Optimization strategies for the cold and warm starts

#aws #serverless #java #database

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 the Data API and Amazon Aurora Serverless v2 with PostgreSQL database, but with a similar scenario using the 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 of memory for the Lambda function. With different memory settings, you might achieve 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 and 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. Other options can be provided to the Lambda function using an 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 and measurements with DynamoDB.
  • Lambda arm64 architecture (which supports SnapStart since July 18, 2024) can provide a good cost-performance trade-off compared 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 an HTTP connection to the database via the 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 an example of using the AWS CRT HTTP client when creating/building the RdsDataClient. URLConnection client can be set similarly.

RdsDataClient.builder().httpClient(AwsCrtHttpClient.create()).build()
Enter fullscreen mode Exit fullscreen mode

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

     <dependency>
        <groupId>software.amazon.awssdk</groupId>
        <artifactId>aws-crt-client</artifactId>
     </dependency>
Enter fullscreen mode Exit fullscreen mode

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 an asynchronous HTTP client for the 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 an example of using a synchronous AWS CRT HTTP client when creating/building the RdsDataAsyncClient (which we need to build in case of using an asynchronous HTTP Client).

RdsDataAsyncClient.builder().httpClient(AwsCrtAsyncHttpClient.create()).build()
Enter fullscreen mode Exit fullscreen mode

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

     <dependency>
        <groupId>software.amazon.awssdk</groupId>
        <artifactId>aws-crt-client</artifactId>
     </dependency>
Enter fullscreen mode Exit fullscreen mode

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 a 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, we 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 a certain number 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 the Data API for Amazon Aurora Serverless v2 with AWS SDK for Java, which you can explore to find out the best performance for your own use case.

Top comments (1)