Einführung

Im Teil 7 der Serie „Daten-API für Amazon Aurora Serverless v2 mit AWS SDK für Java – Daten-API trifft SnapStart“ haben wir die Kalt- und Warmstartzeiten der Lambda-Funktion gemessen, die mithilfe von Daten eine Verbindung zur PostgreSQL-Datenbank von Amazon Aurora Serverless v2 herstellt API für 3 Anwendungsfälle:

• ohne SnapStart für die Lambda-Funktion aktiviert
• mit aktiviertem SnapStart für die Lambda-Funktion, aber ohne Priming-Optimierung
• mit aktiviertem SnapStart für die Lambda-Funktion und mit Priming-Optimierung (Vorwärmung der SQL-Anweisungsausführung in der PostgreSQL-Datenbank).

In diesem Artikel möchten wir diese Messungen mit denen vergleichen, jedoch unter Verwendung von DynamoDB anstelle der Daten-API für Amazon Aurora Serverless v2.

Vergleich von Lambda-Kalt- und Warmstarts: Daten-API für Amazon Aurora Serverless v2 vs. DynamoDB

In meiner Artikelserie über Lambda SnapStart haben wir solche Messungen bereits für die ähnliche Anwendung durchgeführt, aber im Artikel Messung von Warmstarts mit Java 21 unter Verwendung unterschiedlicher Lambda-Speichereinstellungen.

Beide Anwendungen Data API für Amazon Aurora Serverless v2 und DynamoDB sind sehr ähnlich:

• Sie stellen Logik zum Speichern und Abrufen von Produkten aus der Datenbank bereit
• Lambda-Funktionen aus beiden Projekten haben eine Speichereinstellung von 1024 MB
• Die Größe der Bereitstellungsartefakte beträgt für beide etwa 18 MB
• Lambda-Funktionen aus beiden Projekten verwenden den standardmäßigen synchronen HTTP-Apache-Client, um mit Datenbanken zu kommunizieren
• Lambda-Funktionen aus beiden Projekten verwenden die x86_64-Architektur

Fügen wir nun alle Messungen zusammen.

Kalte (c) und warme (m) Startzeit in ms:

Abschluss

In diesem Artikel habe ich Messungen der Kalt- und Warmstartzeiten der Lambda-Funktion, die eine Verbindung zur Amazon Aurora Serverless v2 PostgreSQL-Datenbank mithilfe der Daten-API herstellt, mit der Verbindung zur DynamoDB-Datenbank für drei Anwendungsfälle verglichen:

• ohne SnapStart für die Lambda-Funktion aktiviert
• mit aktiviertem SnapStart für die Lambda-Funktion, aber ohne Priming-Optimierung
• mit aktiviertem SnapStart für die Lambda-Funktion und mit Priming der Datenbankanforderung

Wir haben festgestellt, dass die Kaltstartzeiten ohne Aktivierung von SnapStart für die Lambda-Funktion für beide recht vergleichbar sind. Falls SnapStart aktiviert ist (ohne und insbesondere mit Priming), hat die Daten-API für Amazon Aurora Serverless v2 deutlich längere Kaltstartzeiten, insbesondere für die Perzentile >= 90. Ich muss tiefer graben, um diesen Unterschied zu verstehen, da ich es nicht getan habe Erwarten Sie, dass es so groß ist, insbesondere wenn eine Grundierung aufgetragen wurde. Vielleicht liegt der Grund dafür darin, dass native AWS-Dienste wie DynamoDB SnapStart-fähiger sind. Ich kann besser mit Verbindungsfortsetzungen umgehen.

Die Warmstart-(Ausführungs-)Zeiten waren für die Daten-API für Amazon Aurora Serverless v2 im Vergleich zu DynamoDB konstant viel höher, was ich auch erwartet hatte, da DynamoDB für seine Reaktionszeiten im ein- oder zweistelligen Millisekundenbereich bekannt ist.