Introduction

In the part 1 of the series we set up the sample application which has API Gateway in front of Lambda functions which communicate with Aurora Serverless v2 PostgreSQL database via Data API to create the products and retrieve them (by id). In the part 2 we dove deeper into the new Data API for Aurora Serverless v2 itself and its capabilities like executing SQL Statements and used AWS SDK for Java for it. In the part 3 we took a look at the Data API capabilities to batch SQL statement over an array of data for bulk update and insert operations. In the part 4 we learned how to use database transactions with Data API.
In this part of the series we'll perform some basic measurements of the cold and warm start/execution time of the operation via Data API for Amazon Aurora Serverless v2.

Measuring cold and warm starts of the operation via Data API for Amazon Aurora Serverless v2

In our experiment we'll re-use the application introduced in the part 1 which source code you can find here. There are basically 2 Lambda functions which both respond to the API Gateway requests to store and retrieve product received from the API Gateway from Amazon PostgreSQL Aurora Serverless v2.

The results of the experiment to retrieve the existing product from the database by its id see GetProductByIdViaAuroraServerlessV2DataApiHandler with Lambda function with 1024 MB memory setting were based on reproducing more than 100 cold and approximately 10.000 warm starts with experiment which ran for approximately 1 hour. For it (and experiments from my previous article) I used the load test tool hey, but you can use whatever tool you want, like Serverless-artillery or Postman. We won't enable SnapStart on the Lambda function first.

Cold (c) and warm (m) start time in ms:

Conclusion

In this part of the series performed some basic measurements of the cold and warm start/execution times of the operation via Data API for Amazon Aurora Serverless v2 without enabling SnapStart on the Lambda function. We observed quite a big cold start times but also the first call additionally results in the bigger warm start (execution time) as the database connection needs to be initialized on the database side. So, especially the very first execution and the subsequent ones where the cold starts occurs together with database connection initialization on the database side are very expensive.

In the next part of the series we'll perform the measurements but with using the standard connection management approaches (in case of Java with JDBC) including the usage of Amazon RDS Proxy.