


Spring Boot-Anwendung auf AWS Lambda – Teil Messung von Kalt- und Warmstarts mit GraalVM Native Image und Speichereinstellungen
Jan 07, 2025 am 07:17 AMEinführung
Im Artikel Teil 12 unserer Serie haben wir untersucht, wie man eine Lambda-Funktion mit einer benutzerdefinierten Laufzeit entwickelt und bereitstellt, die ein GraalVM Native Image mit einer GraalVM 22-Laufzeit enth?lt, die aus der AWS-Anwendung Spring Cloud Function erstellt wurde. Im Teil 13 haben wir die Leistung (Kalt- und Warmstarts) einer solchen Lambda-Funktion mit 1024 MB Speicher gemessen.
In diesem Artikel messen wir die Leistung (Kalt- und Warmstarts) der Lambda-Funktion mithilfe dieses Ansatzes mit verschiedenen Speichereinstellungen zwischen 256 und 1536 MB, um den Kompromiss zwischen Kosten und Leistung zu untersuchen.
Messen von Kalt- und Warmstarts der Lambda-Funktion mit Custom Runtime, das GraalVM Native Image mit unterschiedlichen Speichereinstellungen enth?lt
Wir werden genau das gleiche Experiment wiederholen, das in Teil 13 dieser Artikelserie beschrieben wurde, jedoch mit unterschiedlichen Speichereinstellungen zwischen 256 und 1536 MB.
Hier sind die Ergebnisse des Experiments:
Kalt (c) und warm (m) Startzeit in ms:
Memory setting | 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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
256 MB | 1634.84 | 1659.54 | 1691.35 | 1778.03 | 1785.15 | 1785.7 | 6.56 | 6.99 | 7.63 | 18.33 | 372.54 | 857.7 |
512 MB | 1244.44 | 1278.48 | 1313.45 | 1414.28 | 1421.36 | 1421.94 | 6.66 | 7.10 | 7.94 | 25.41 | 181.86 | 414.99 |
768 MB | 1111.53 | 1126.07 | 1139.66 | 1192.08 | 1202.86 | 1203.07 | 6.58 | 6.93 | 7.48 | 12.46 | 115.18 | 278.91 |
1024 MB | 1051.03 | 1061.58 | 1080.86 | 1119.34 | 1149.45 | 1230.28 | 6.45 | 6.77 | 7.33 | 12.50 | 90.92 | 218.17 |
1280 MB | 1022.02 | 1035.39 | 1058.41 | 1065.76 | 1104.64 | 1174.79 | 6.58 | 6.96 | 7.54 | 12.37 | 70.77 | 271.13 |
1536 MB | 1009.83 | 1029.20 | 1048.41 | 1161.32 | 1116.24 | 1148.24 | 6.66 | 7.04 | 7.75 | 12.08 | 63.03 | 215.62 |
Abschluss
In diesem Artikel werden Kalt- und Warmstarts der Lambda-Funktion unter Verwendung einer benutzerdefinierten Laufzeit gemessen, die ein GraalVM Native Image mit einer GraalVM 21-Laufzeit enth?lt, die aus der in Teil 12 eingeführten AWS-Anwendung Spring Cloud Function erstellt wurde und unterschiedliche Speichereinstellungen zwischen 256 und 1536 MB aufweist.
Wir beobachten ?hnliche Dinge wie im Artikel Pure Lambda-Funktion mit GraalVM Native Image – Messen von Kalt- und Warmstarts mit unterschiedlichen Lambda-Speichereinstellungen beschrieben. Die Warmstartzeiten liegen auch bei der niedrigeren Lambda-Funktionsspeichereinstellung wie 256 oder 512 MB sehr nahe beieinander, wobei der Unterschied haupts?chlich bei den hohen Perzentilen sichtbar ist (>= p90). Die Kaltstartzeiten sind bei 256 und 512 MB recht hoch und ab 768 MB Speicher verringern sie sich nur geringfügig, indem Lambda mehr Speicher zur Verfügung gestellt wird, bei Speicher gr??er als 1024 MB ist jedoch kein Unterschied erkennbar. Abh?ngig von Ihren Leistungsanforderungen k?nnen Sie Lambda weniger Speicher als 1024 MB geben, wie wir ursprünglich in der Beispielanwendung angegeben haben, und haben mit 768 MB oder sogar etwas weniger Speicher einen sehr guten Preis-Leistungs-Kompromiss.
Wir haben auch die gleichen Beobachtungen geteilt, die im Fazit von Teil 13 beschrieben wurden. Wenn wir Kaltstartzeiten mit den im Artikel Pure Lambda-Funktion mit GraalVM Native Image – Messen von Kalt- und Warmstarts mit unterschiedlichen Lambda-Speichereinstellungen gemessenen Zeiten vergleichen ( Wenn die Lambda-Funktion kein Framework wie Spring Boot verwendet), sehen wir bei Verwendung der reinen Lambda-Funktion Werte, die für jedes Perzentil um etwa 0,5 bis 0,6 Sekunden niedriger sind. Ich pers?nlich denke, dass meine Beispiel-Spring Boot 3-Anwendung ein gewisses Optimierungspotenzial hat, da ich mir einen so gro?en Unterschied in den Kaltstartzeiten zwischen diesen nicht erkl?ren kann. Meine (vielleicht naive) Erwartung ist, dass die Verwendung des Spring Boot 3-Frameworks mit AWS Lambda und GraalVM Native Image m?glicherweise nur zu 0,2–0,3 h?heren Kaltstartzeiten im Vergleich zur Verwendung der reinen Lambda-Funktion führt.
Zum Zeitpunkt der Ver?ffentlichung dieses Artikels waren neuere Versionen der verwendeten Frameworks und Tools verfügbar (GraalVM 23-Laufzeitumgebung, Spring Boot 3.4 und Versionsaktualisierung der Spring Cloud-Funktionsbibliothek). Nehmen Sie daher gegebenenfalls die Versions?nderungen vor und kompilieren Sie GraalVM Native neu Bild nach den Anweisungen aus Teil 2 der Serie und messen Sie die Leistung erneut. Ich werde auch bald die neuen Messungen mit diesen Versionen ver?ffentlichen und die Beispielanwendung aktualisieren.
Das obige ist der detaillierte Inhalt vonSpring Boot-Anwendung auf AWS Lambda – Teil Messung von Kalt- und Warmstarts mit GraalVM Native Image und Speichereinstellungen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Hei?e KI -Werkzeuge

Undress AI Tool
Ausziehbilder kostenlos

Undresser.AI Undress
KI-gestützte App zum Erstellen realistischer Aktfotos

AI Clothes Remover
Online-KI-Tool zum Entfernen von Kleidung aus Fotos.

Clothoff.io
KI-Kleiderentferner

Video Face Swap
Tauschen Sie Gesichter in jedem Video mühelos mit unserem v?llig kostenlosen KI-Gesichtstausch-Tool aus!

Hei?er Artikel

Hei?e Werkzeuge

Notepad++7.3.1
Einfach zu bedienender und kostenloser Code-Editor

SublimeText3 chinesische Version
Chinesische Version, sehr einfach zu bedienen

Senden Sie Studio 13.0.1
Leistungsstarke integrierte PHP-Entwicklungsumgebung

Dreamweaver CS6
Visuelle Webentwicklungstools

SublimeText3 Mac-Version
Codebearbeitungssoftware auf Gottesniveau (SublimeText3)

Hei?e Themen

Der Unterschied zwischen HashMap und Hashtable spiegelt sich haupts?chlich in der Gewindesicherheit, der Nullwertunterstützung und der Leistung wider. 1. In Bezug auf die Gewindesicherheit ist Hashtable Thread-Safe, und seine Methoden sind haupts?chlich Synchronmethoden, w?hrend HashMap keine Synchronisationsverarbeitung durchführt, die nicht mit Thread-Safe ist. 2. In Bezug auf die Nullwertunterstützung erm?glicht HashMap einen Nullschlüssel und mehrere Nullwerte, w?hrend Hashtable keine Nullschlüssel oder -Werte zul?sst, sonst wird eine Nullpointerexception geworfen. 3. In Bezug auf die Leistung ist HashMap effizienter, da kein Synchronisationsmechanismus vorhanden ist und Hashtable für jeden Vorgang eine niedrige Verriegelungsleistung aufweist. Es wird empfohlen, stattdessen eine Concurrenthashmap zu verwenden.

Java verwendet Wrapper-Klassen, da grundlegende Datentypen nicht direkt an objektorientierten Operationen teilnehmen k?nnen und Objektformen h?ufig in den tats?chlichen Bedürfnissen erforderlich sind. 1. Sammelklassen k?nnen nur Objekte speichern, z. B. Listen verwenden automatische Boxen, um numerische Werte zu speichern. 2. Generika unterstützen keine Grundtypen, und Verpackungsklassen müssen als Typparameter verwendet werden. 3.. Verpackungsklassen k?nnen Nullwerte darstellen, um nicht festgelegte oder fehlende Daten zu unterscheiden. 4. Verpackungsklassen bieten praktische Methoden wie String -Conversion, um die Analyse und Verarbeitung von Daten zu erleichtern. In Szenarien, in denen diese Eigenschaften ben?tigt werden, sind Verpackungsklassen unverzichtbar.

StaticMethodsinInterfaces -reisEtroducucuedInjava8toalloytilityFunctionSwitHinTheInterfaceItEp.beejava8, solche Funktionen, dieseparatehelperklassen, führendemTodisorganizedCode.Now, StaticMetheSprovidreefits: 1) theeneNableable -theenableaby

Der JIT -Compiler optimiert den Code durch vier Methoden: Methode Inline, Hotspot -Erkennung und -vergleich, Typespekulation und Devirtualisation sowie die Eliminierung des redundanten Betriebs. 1. Methode Inline reduziert den Anrufaufwand und fügt h?ufig kleine Methoden direkt in den Anruf ein. 2. Erkennung und Hochfrequenzcodeausführung und zentral optimieren, um Ressourcen zu sparen. 3. Typ Spekulation sammelt Informationen zum Laufzeittyp, um Devirtualisation -Anrufe zu erzielen und die Effizienz zu verbessern. 4. Redundante Operationen beseitigen nutzlose Berechnungen und Inspektionen basierend auf den Betriebsdaten, wodurch die Leistung verbessert wird.

Instanzinitialisierungsbl?cke werden in Java verwendet, um die Initialisierungslogik beim Erstellen von Objekten auszuführen, die vor dem Konstruktor ausgeführt werden. Es ist für Szenarien geeignet, in denen mehrere Konstruktoren Initialisierungscode, komplexe Feldinitialisierung oder anonyme Szenarien der Klasseninitialisierung teilen. Im Gegensatz zu statischen Initialisierungsbl?cken wird es jedes Mal ausgeführt, wenn es instanziiert wird, w?hrend statische Initialisierungsbl?cke nur einmal ausgeführt werden, wenn die Klasse geladen wird.

InvaVa, theFinalKeywordPreventsAvariable von ValueFromBeingumedAfterasssignment, ButitsBehaviordiffersForprimitive und ANSPRIMITIVEVARIABLE, FinalMakesthevalueconstant, AsinfinalIntmax_speed = 100; WhirerastsignmentcausaSesSaSesSaSesSaSaSesSaSesSaSaSesSaSaSesSaSesSesirror

Der Werksmodus wird verwendet, um die Logik der Objekterstellung zusammenzufassen, wodurch der Code flexibler, einfach zu pflegen und locker gekoppelt ist. Die Kernantwort lautet: Durch zentrales Verwalten von Logik der Objekterstellung, das Ausblenden von Implementierungsdetails und die Unterstützung der Erstellung mehrerer verwandter Objekte. Die spezifische Beschreibung lautet wie folgt: Der Fabrikmodus gibt Objekterstellung an eine spezielle Fabrikklasse oder -methode zur Verarbeitung und vermeidet die Verwendung von NewClass () direkt; Es ist für Szenarien geeignet, in denen mehrere Arten von verwandten Objekten erstellt werden, die Erstellungslogik sich ?ndern und Implementierungsdetails versteckt werden müssen. Zum Beispiel werden im Zahlungsabwickler Stripe, PayPal und andere Instanzen durch Fabriken erstellt. Die Implementierung umfasst das von der Fabrikklasse zurückgegebene Objekt basierend auf Eingabeparametern, und alle Objekte erkennen eine gemeinsame Schnittstelle. Gemeinsame Varianten umfassen einfache Fabriken, Fabrikmethoden und abstrakte Fabriken, die für unterschiedliche Komplexit?ten geeignet sind.

Es gibt zwei Arten von Konvertierung: implizit und explizit. 1. Die implizite Umwandlung erfolgt automatisch, wie z. B. das Konvertieren in INT in Doppel; 2. Explizite Konvertierung erfordert einen manuellen Betrieb, z. B. die Verwendung (int) MyDouble. Ein Fall, in dem die Typ -Konvertierung erforderlich ist, umfasst die Verarbeitung von Benutzereingaben, mathematische Operationen oder das übergeben verschiedener Werte zwischen Funktionen. Probleme, die beachtet werden müssen, sind: Umdrehung von Gleitpunktzahlen in Ganzzahlen wird der fraktionale Teil abschneiden, gro?e Typen in kleine Typen zu einem Datenverlust führen, und einige Sprachen erm?glichen keine direkte Konvertierung bestimmter Typen. Ein ordnungsgem??es Verst?ndnis der Regeln der Sprachkonvertierung hilft, Fehler zu vermeiden.
