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

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

王林
王林Original
2024-07-23 11:17:43959Durchsuche

Data API for Amazon Aurora Serverless vith AWS SDK for Java - Part omparing cold and warm starts: Data 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 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ä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, um mit Datenbanken zu kommunizieren
  • Lambda-Funktionen aus beiden Projekten verwenden die x86_64-Architektur

Fügen wir nun alle Maße zusammen.

Kalt (c) und warm (m) Startzeit 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

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 Priming-Optimierung
  • mit aktiviertem SnapStart für die Lambda-Funktion und mit Vorbereitung der Datenbankanforderung

Wir haben festgestellt, 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 das daran, dass AWS-native 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.

Das obige ist der detaillierte Inhalt vonDaten-API für Amazon Aurora Serverless mit AWS SDK für Java – Teil zum Vergleich von Kalt- und Warmstarts: Daten-API vs. DynamoDB. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn