


Einfü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!

Der Klassenlader stellt die Konsistenz und Kompatibilität von Java-Programmen auf verschiedenen Plattformen durch ein einheitliches Klassendateiformat, dynamische Lade-, übergeordnete Delegationsmodell und plattformunabhängige Bytecode und erreicht Plattformunabhängigkeit.

Der vom Java-Compiler generierte Code ist plattformunabhängig, aber der Code, der letztendlich ausgeführt wird, ist plattformspezifisch. 1. Java-Quellcode wird in plattformunabhängige Bytecode zusammengestellt. 2. Die JVM wandelt Bytecode für eine bestimmte Plattform in den Maschinencode um und stellt den plattformübergreifenden Betrieb sicher, aber die Leistung kann unterschiedlich sein.

Multithreading ist für die moderne Programmierung wichtig, da es die Reaktionsfähigkeit und die Nutzung der Ressourcen verbessern und komplexe gleichzeitige Aufgaben erledigen kann. JVM sorgt für die Konsistenz und Effizienz von Multithreads auf verschiedenen Betriebssystemen durch Thread Mapping, Planungsmechanismus und Synchronisationssperrmechanismus.

Die Unabhängigkeit von Java's Platform bedeutet, dass der geschriebene Code auf jeder Plattform mit JVM ohne Änderung ausgeführt wird. 1) Java -Quellcode wird in Bytecode, 2) Bytecode kompiliert und von der JVM, 3) interpretiert und ausgeführt, 3) Die JVM bietet Speicherverwaltung und Müllsammlungsfunktionen, um sicherzustellen, dass das Programm auf verschiedenen Betriebssystemen ausgeführt wird.

JavaapplicationscanindeNecounterplatform-spezifische SpezifikationsDespitethejvm'Sabstraction.Reassinclude: 1) NativeCodeandlibraries, 2) Operatingsystemdifferenzen, 3) jvmimplementationVarias und 4) Hardwaredependenz

Cloud Computing verbessert die Unabhängigkeit der Java -Plattform erheblich. 1) Der Java-Code wird in Bytecode zusammengestellt und von der JVM auf verschiedenen Betriebssystemen ausgeführt, um einen plattformübergreifenden Betrieb sicherzustellen. 2) Verwenden Sie Docker und Kubernetes, um Java -Anwendungen bereitzustellen, um die Portabilität und Skalierbarkeit zu verbessern.

Java'SplatformIndependenceAllowsDeveloToWriteCodeonceAnDrunitonanyDeviceOroswithajvm.Thissisached ThroughCompilingTobyteCode, die thejvMinterpretSorcompilesatruntime.thisfeaturehasseboostedjavaSadoToToToToToToToToToToToToToDoToToToToTionDe-Signifikant-

Containerisierungstechnologien wie Docker verbessern anstatt die Unabhängigkeit der Plattform der Java zu ersetzen. 1) Gewährleistung der Konsistenz zwischen Umgebungen, 2) Verwalten von Abhängigkeiten, einschließlich spezifischer JVM -Versionen, 3) Vereinfachen Sie den Bereitstellungsprozess, um JAVA -Anwendungen anpassungsfähiger und überschaubarer zu gestalten.


Heiße KI -Werkzeuge

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

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

Undress AI Tool
Ausziehbilder kostenlos

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

ZendStudio 13.5.1 Mac
Leistungsstarke integrierte PHP-Entwicklungsumgebung

SAP NetWeaver Server-Adapter für Eclipse
Integrieren Sie Eclipse mit dem SAP NetWeaver-Anwendungsserver.

DVWA
Damn Vulnerable Web App (DVWA) ist eine PHP/MySQL-Webanwendung, die sehr anfällig ist. Seine Hauptziele bestehen darin, Sicherheitsexperten dabei zu helfen, ihre Fähigkeiten und Tools in einem rechtlichen Umfeld zu testen, Webentwicklern dabei zu helfen, den Prozess der Sicherung von Webanwendungen besser zu verstehen, und Lehrern/Schülern dabei zu helfen, in einer Unterrichtsumgebung Webanwendungen zu lehren/lernen Sicherheit. Das Ziel von DVWA besteht darin, einige der häufigsten Web-Schwachstellen über eine einfache und unkomplizierte Benutzeroberfläche mit unterschiedlichen Schwierigkeitsgraden zu üben. Bitte beachten Sie, dass diese Software

VSCode Windows 64-Bit-Download
Ein kostenloser und leistungsstarker IDE-Editor von Microsoft

SublimeText3 Mac-Version
Codebearbeitungssoftware auf Gottesniveau (SublimeText3)