AWS Lambda-Leistung mit Java xvs arm – Teilanfangsmessungen

Einführung

Bis jetzt habe ich die Leistung (Warm- und Kaltstartzeiten) der Lambda-Funktionen mit der Java 21-Laufzeit für einige Anwendungsfälle (z. B. das Erstellen einer DynamoDB-Anfrage) für die arm64-Architektur nicht gemessen, da SnapStart nicht unterstützt wird. Lambda mit Java 21-Laufzeitumgebung mit x86_64-Architektur und aktiviertem SnapStart wird Lambda mit arm64-Architektur übertreffen (sogar noch mehr mit zusätzlicher Priming-Optimierung). Doch am 18. Juli 2024 gab AWS bekannt, dass AWS Lambda nun SnapStart für Java-Funktionen unterstützt, die die ARM64-Architektur nutzen. Daher war es für mich jetzt sinnvoll, mit der Messung der Kalt- und Warmstartzeiten zu beginnen, auch unter Berücksichtigung der Wahl der Architektur der Lambda-Funktion. Es ist bekannt, dass Lambda mit arm64-Architektur mit der aktuellen AWS Lambda-Preisspeichereinstellung und Ausführungsdauer ca. 25 % günstiger als Lambda mit x86_64-Architektur.

Ich habe beschlossen, eine separate Artikelserie dafür zu erstellen und dieses Thema nicht zu meiner ständig wachsenden AWS Lambda SnapStart-Serie hinzuzufügen.

Messung der Kalt- und Warmstarts für die Beispielanwendung

In unserem Experiment verwenden wir die im Artikel AWS Lambda SnapStart – Messen von Java 21 Lambda-Kaltstarts vorgestellte Anwendung wieder. Hier ist der Code für die Beispielanwendung. Grundsätzlich gibt es zwei Haupt-Lambda-Funktionen, die beide auf die API-Gateway-Anfragen reagieren, um das Produkt mit der angegebenen ID zu erstellen (siehe Lambda-Funktion PutProductFunction) und das Produkt mit der angegebenen ID abzurufen (siehe Lambda-Funktion GetProductByIdFunction). Sie können beide Lambda-Funktionen mit und ohne aktiviertem SnapStart verwenden. Es gibt eine zusätzliche Lambda-Funktion „GetProductByIdWithPrimingFunction“, die ich geschrieben habe, um die Auswirkung des DynamoDB-Anforderungsprimings für die SnapStart-fähige Lambda-Funktion unabhängig zu messen. Mehr über die Wirkung des Primings können Sie in meinem Artikel AWS Lambda SnapStart – Messung von Priming, End-to-End-Latenz und Bereitstellungszeit lesen.

Um SnapStart für alle Lambda-Funktionen zu aktivieren, entkommentieren Sie bitte Folgendes in der SAM-Vorlage:

Globals:
  Function:
    CodeUri: target/aws-pure-lambda-snap-start-21-1.0.0-SNAPSHOT.jar
    ...
    SnapStart:
     ApplyOn: PublishedVersions  
   ...

Wenn ich SnapStart nur für die einzelnen, aber nicht alle Lambda-Funktionen verwenden möchte, müssen Sie diese SnapStart-Definition auf der Lambda-Funktionsebene anstelle der globalen Funktionsebene anwenden.

Alle Lambda-Funktionen haben die folgenden Einstellungen als Ausgangspunkt:

• 1024 MB Speichereinstellung
• Standard-HTTP-Apache-Client, der zur Kommunikation mit der DynamoDB-Datenbank verwendet wird
• Java-Kompilierungsoption „-XX:+TieredCompilation -XX:TieredStopAtLevel=1“, die sich als sehr guter Kompromiss zwischen den Kalt- und Warmstartzeiten erwiesen hat

In der SAM-Vorlage habe ich die Möglichkeit hinzugefügt, die Lambda-Architektur im globalen Lambda-Funktionsabschnitt wie folgt zu definieren:

Globals:
  Function:
    CodeUri: target/aws-pure-lambda-snap-start-21-1.0.0-SNAPSHOT.jar
    ...
    Architectures:
      #- arm64
      - x86_64   

Kommentieren Sie einfach die Architektur aus, die Sie für Ihre Lambda-Funktionen verwenden möchten.

Auch wenn Java „einmal schreiben, überall ausführen“ bedeutet, habe ich die Anwendungs-JAR-Datei für meine arm64-Messungen auf der t4g AWS EC2-Instanz mit Graviton-Prozessor (der auf der arm64/aarch64-Architektur basiert) durch vorherige Installation kompiliert und erstellt Amazon Corretto 21 für Linux aarch64. Dieses Glas finden Sie hier.

Ich habe auch alles für die x86_64-Architektur noch einmal neu gemessen, um vergleichbare Ergebnisse mit derselben neuesten Laufzeitversion von Corretto Java 21 zu erhalten, die zum Zeitpunkt meiner Messungen Java 21.v17 war.

Die Ergebnisse des folgenden Experiments basierten auf der Reproduktion von mehr als 100 Kalt- und etwa 100.000 Warmstarts. Dafür (und Experimente aus meinem vorherigen Artikel) habe ich das Lasttest-Tool verwendet, aber Sie können jedes beliebige Tool verwenden, z. B. Serverless-Artillery oder Postman. Es ist auch wichtig zu wissen, dass ich mit den Messungen unmittelbar nach der (Neu-)Bereitstellung des neuen Quellcodes der Anwendung begonnen habe. Bitte beachten Sie, dass es auch Auswirkungen des Snapshot-Tiered-Cache auf Kaltstarts gibt, bei denen die ersten Aufrufe im Allgemeinen langsamer sind und die nachfolgenden schneller werden, bis eine bestimmte Anzahl von Aufrufen erreicht ist.

Jetzt können wir alle Messungen für den Fall „Produkt anhand vorhandener ID abrufen“ (Lambda-Funktionen GetProductByIdFunction und GetProductByIdWithPrimingFunction für aktivierte SnapStart- und Grundierungsmessungen) zusammenfassen.

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
x86_64, no SnapStart enabled	3554.30	3615.21	3666.15	3800.47	4108.61	4111.78	5.42	6.01	6.88	14.09	40.98	1654.59
arm64, no SnapStart enabled	3834.81	3904.42	3983.26	4047.47	4332.13	4335.74	5.96	6.66	7.69	16.01	43.68	1844.54
x86_64, SnapStart enabled without priming	1794.09	1846.86	2090.54	2204.27	2239.80	2240.08	5.37	5.96	6.93	15.88	51.64	1578.34
arm64, SnapStart enabled without priming	1845.01	1953.18	2591.70	2762.91	2793.45	2795.8	5.91	6.56	7.63	16.75	63.52	1779.14
x86_64, SnapStart enabled with DynamoDB request priming	803.18	870.18	1103.78	1258.19	1439.95	1440.67	5.55	6.25	7.45	15.50	63.52	448.85
arm64, SnapStart enabled with DynamoDB request priming	910.14	1001.79	1376.62	1623.44	1684.60	1686.19	6.05	6.72	7.81	16.66	74.68	550.59

Abschluss

In diesem Artikel haben wir Messungen der Kalt- und Warmstartzeiten der Lambda-Funktion, die eine Verbindung zur DynamoDB-Datenbank herstellt, 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 DynamoDB-Anfrage

Wir haben gesehen, dass bei Verwendung der x86_64-Architektur alle Kalt- und Warmstartzeiten im Vergleich zur arm64-Architektur kürzer waren. Aber da die Lambda-Preise für die arm64-Architektur 25 % günstiger sind als für die x86_64-Architektur, führt dies zu einem sehr interessanten Preis-Leistungs-Kompromiss.

Für unsere Messungen, für alle 3 Anwendungsfälle:

• Lambda-Kaltstartzeiten mit arm64-Architektur waren für viele Perzentile nur 10–20 % (und nur in sehr seltenen Fällen 25–27 %) langsamer im Vergleich zur x86_64-Architektur.
• Lambda-Warmstartzeiten waren mit der ARM64-Architektur für viele Perzentile nur 5–10 % langsamer als mit der x86_64-Architektur.

Daher ist die Wahl der arm64-Architektur für diese Beispielanwendung durchaus sinnvoll. Da die SnapStart-Unterstützung für die arm64-Architektur erst vor kurzem eingeführt wurde, erwarte ich auch in Zukunft einige Leistungsverbesserungen. Bitte führen Sie Ihre eigenen Messungen für Ihren Anwendungsfall durch!

Im nächsten Teil des Artikels führen wir die gleichen Leistungsmessungen durch, stellen den Lambda-Speicher jedoch auf unterschiedliche Werte zwischen 256 und 2048 MB ein und vergleichen die Ergebnisse.

Das obige ist der detaillierte Inhalt vonAWS Lambda-Leistung mit Java xvs arm – Teilanfangsmessungen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!