Data API for Amazon Aurora Serverless vith AWS SDK for Java - Part omparing cold and warm starts: Data API vs DynamoDB

Introduction

In the part 7 of the series Data API for Amazon Aurora Serverless v2 with AWS SDK for Java - Data API meets SnapStart we measured the cold and warm start times of the Lambda function connecting to the Amazon Aurora Serverless v2 PostgreSQL database using Data API for 3 use cases :

• without SnapStart enabled on the Lambda function
• with SnapStart enabled on the Lambda function but without priming optimization
• with SnapStart enabled on the Lambda function and with priming optimization (pre-warming SQL statement execution on the PostgreSQL database).

In this article we'd like to compare those measurements with those but with using DynamoDB instead of Data API for Amazon Aurora Serverless v2.

Comparing Lambda cold and warm starts: Data API for Amazon Aurora Serverless v2 vs DynamoDB

In my article series about Lambda SnapStart we've already done such measurements for the similar application but in the article Measuring warm starts with Java 21 using different Lambda memory settings .

Both applications Data API for Amazon Aurora Serverless v2 and DynamoDB are very similar :

• They provide logic to store and retrieve products from the database
• Lambda functions from both projects have 1024 MB memory setting
• The deployment artifact sizes are around 18 MB for both
• Lambda functions from both projects use default synchronous HTTP Apache client to communicate with databases
• Lambda functions from both projects use x86_64 architecture

Now lets put all measurements together.

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

Approach	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
Data API, no SnapStart enabled	3154.35	3237	3284.91	3581.49	3702.12	3764.92	104.68	173.96	271.32	572.11	1482.89	2179.7
DynamoDB, no SnapStart enabled	3157.6	3213.85	3270.8	3428.2	3601.12	3725.02	5.77	6.50	7.81	20.65	90.20	1423.63
Data API, SnapStart enabled without priming	1856.11	1994.61	2467.83	3229.11	3238.80	3241.75	61.02	113.32	185.37	639.35	1973.30	2878.5
DynamoDB, SnapStart enabled without priming	1626.69	1741.10	2040.99	2219.75	2319.54	2321.64	5.64	6.41	7.87	21.40	99.81	1355.09
Data API, SnapStart enabled with priming	990.84	1069.04	1634.84	2120.00	2285.03	2286.9	60.06	106.35	185.37	581.27	1605.37	2658.24
DynamoDB, SnapStart enabled with priming	702.55	759.52	1038.50	1169.66	1179.05	1179.36	5.73	6.51	7.87	21.75	92.19	328.41

Conclusion

In this article I compared measurements of the cold and warm start times of the Lambda function connecting to the Amazon Aurora Serverless v2 PostgreSQL database using Data API vs connecting to DynamoDB database for 3 use cases:

• without SnapStart enabled on the Lambda function
• with SnapStart enabled on the Lambda function but without priming optimization
• with SnapStart enabled on the Lambda function and with priming of the database request

What we observed is that cold start times without enabling SnapStart on the Lambda function are quite comparable for both. In case SnapStart is enabled (without and especially with priming) the Data API for Amazon Aurora Serverless v2 has significantly higher cold start times, especially for the percentiles >= 90. I will need to dig deeper to understand this difference as I didn't expect it to be that big, especially if priming was applied. Maybe the reason for that is that AWS native services like DynamoDB are more SnapStart-aware I can deal better with connection resumes.

The warm start (execution) times were constantly much higher for Data API for Amazon Aurora Serverless v2 comparing to DynamoDB which I also expected as DynamoDB is known for its single- or double-digit milliseconds response times.

The above is the detailed content of Data API for Amazon Aurora Serverless vith AWS SDK for Java - Part omparing cold and warm starts: Data API vs DynamoDB. For more information, please follow other related articles on the PHP Chinese website!