Daten-API für Amazon Aurora Serverless mit AWS SDK für Java – Teil zum Vergleich von Kalt- und Warmstarts: Daten-API vs. DynamoDB

Einführung

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

• ohne SnapStart für die Lambda-Funktion aktiviert
• mit aktiviertem SnapStart für die Lambda-Funktion, aber ohne Ansaugoptimierung
• mit aktiviertem SnapStart für die Lambda-Funktion und mit Priming-Optimierung (Vorwärmen 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 verschiedener Lambda-Speichereinstellungen .

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

• Sie bieten Logik zum Speichern und Abrufen von Produkten aus der Datenbank
• 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 für die Kommunikation mit Datenbanken
• Lambda-Funktionen aus beiden Projekten verwenden die x86_64-Architektur

Jetzt fassen wir alle Maße 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 über die 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 Ansaugoptimierung
• mit aktiviertem SnapStart für die Lambda-Funktion und mit Vorbereitung der Datenbankanforderung

Was wir beobachtet haben, ist, dass die Kaltstartzeiten ohne Aktivierung von SnapStart in der 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. Ich erwarte nicht, dass es so groß wird, 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.

以上是Daten-API für Amazon Aurora Serverless mit AWS SDK für Java – Teil zum Vergleich von Kalt- und Warmstarts: Daten-API vs. DynamoDB的详细内容。更多信息请关注PHP中文网其他相关文章！