Haftungsausschluss: Alle veröffentlichten Inhalte dienen dazu, mein Wissen in Erinnerung zu rufen oder aufrechtzuerhalten, und ich hoffe, dass es Ihnen auch auf Ihrem Lernweg helfen kann.
Dieser Beitrag ist live und wird regelmäßig aktualisiert.
Wenn Sie Mängel finden oder bemerken, dass etwas fehlt, helfen Sie mir, mich zu verbessern :)
Haben Sie jemals darüber nachgedacht, dass die Anforderungen an die Leistung unserer Anwendungen immer größer werden?
Jeden Tag werden wir ermutigt, sie schneller zu machen, und so werden wir dazu gebracht, Lösungen und Architekturen zu evaluieren, die es uns ermöglichen, das gewünschte Ergebnis zu erzielen.
Die Idee besteht also darin, einen kurzen Beitrag zu veröffentlichen, der über eine neue Entwicklung informiert, die uns dabei helfen kann, eine erhebliche Leistungssteigerung bei serverlosen Anwendungen in AWS Lambda zu erzielen. Diese Lösung ist LLRT Javascript.
LLRT Javascript (Low Latency Runtime Javascript)
Eine neue Javascript-Laufzeitumgebung wird vom aws-Team entwickelt.
Es ist derzeit experimentell und es gibt Bemühungen, bis Ende 2024 eine stabile Version zu veröffentlichen.
siehe die Beschreibung, die AWS präsentiert:
LLRT (Low Latency Runtime) ist eine leichte JavaScript-Laufzeit, die entwickelt wurde, um der wachsenden Nachfrage nach schnellen und effizienten serverlosen Anwendungen gerecht zu werden. LLRT bietet einen bis zu über 10-mal schnelleren Start und insgesamt bis zu 2-mal geringere Kosten im Vergleich zu anderen JavaScript-Laufzeiten, die auf AWS Lambda ausgeführt werden
Es ist in Rust erstellt und nutzt QuickJS als JavaScript-Engine, um eine effiziente Speichernutzung und einen schnellen Start zu gewährleisten.
Achten Sie darauf, dass sie darauf abzielen, etwas zu liefern, das bis zu 10-mal schneller ist als andere JS-Laufzeiten.
Diese gesamte Konstruktion erfolgt mit Rust, einer Hochleistungssprache, und QuickJS, einer leichten, leistungsstarken JavaScript-Engine, die klein, effizient und mit der neuesten ECMAScript-Spezifikation kompatibel ist moderne Funktionen wie Klassen, Async/Await und Module. Darüber hinaus wird ein Ansatz verwendet, der nicht auf JIT zurückgreift. Anstatt also Ressourcen für die Just-In-Time-Kompilierung zuzuweisen, werden diese Ressourcen für die Ausführung von Aufgaben innerhalb des Codes selbst eingespart.
Aber keine Sorge, nicht alles ist rosig, es sind Kompromisse (schreckliches Wortspiel, ich weiß, lol).
Daher müssen einige wichtige Punkte beachtet werden, bevor über die Einführung von LLRT JS nachgedacht wird. Sehen Sie, was AWS sagt:
Es gibt viele Fälle, in denen LLRT im Vergleich zu JIT-basierten Laufzeiten erhebliche Leistungsnachteile aufweist, wie z. B. bei der Verarbeitung großer Datenmengen, Monte-Carlo-Simulationen oder der Ausführung von Aufgaben mit Hunderttausenden oder Millionen von Iterationen. LLRT ist am effektivsten, wenn es auf kleinere serverlose Funktionen angewendet wird, die sich Aufgaben wie Datentransformation, Echtzeitverarbeitung, AWS-Serviceintegrationen, Autorisierung, Validierung usw. widmen. Es soll bestehende Komponenten ergänzen und nicht als umfassender Ersatz für alles dienen. Da die unterstützten APIs auf der Node.js-Spezifikation basieren, erfordert der Übergang zurück zu alternativen Lösungen nur minimale Codeanpassungen.
Außerdem besteht die Idee darin, dass LLRT JS kein Ersatz für node.js ist und es auch nie sein wird.
Siehe:
LLRT unterstützt nur einen Bruchteil der Node.js-APIs. Es ist KEIN Ersatz für Node.js und wird es auch nie sein. Nachfolgend finden Sie eine allgemeine Übersicht über teilweise unterstützte APIs und Module. Weitere Einzelheiten finden Sie in der API-Dokumentation.
Bewertungstests
Unter Berücksichtigung der von AWS selbst erwähnten Anwendbarkeit werden wir zwei Tests durchführen, um LLRT mit NodeJS zu bewerten und zu vergleichen. Einer der Tests dient der Berechnung von Primzahlen und der andere einem einfachen API-Aufruf.
Warum die Berechnung von Primzahlen verwenden?
Die Antwort ist, dass der hohe Verarbeitungsaufwand zur Identifizierung von Primzahlen auf die Notwendigkeit zurückzuführen ist, viele mathematische Operationen (Divisionen) zur Überprüfung der Primzahl durchzuführen, auf die unvorhersehbare Verteilung von Primzahlen und auf die mit der Größe der Zahlen zunehmende Komplexität. Diese Faktoren machen die Primalitätsprüfung und die Suche nach Primzahlen zu einer rechenintensiven Aufgabe, insbesondere in großen Maßstäben.
Dann greifen Sie zu...
Erstellen Sie die erste Lambda-Funktion mit nodejs:
Jetzt erstellen wir die Funktion mit LLRT JS. Ich habe mich für die Ebenenoption entschieden.
Erstellen Sie die Ebene:
Dann erstellen Sie die Funktion:
Und fügen Sie diese Ebene zur erstellten LLRT JS-Funktion hinzu:
Für den Primzahltest verwenden wir den folgenden Code:
let isLambdaWarm = false
export async function handler(event) {
const limit = event.limit || 100000; // Defina um limite alto para aumentar a complexidade
const primes = [];
const startTime = Date.now()
const isPrime = (num) => {
if (num <= 1) return false;
if (num <= 3) return true;
if (num % 2 === 0 || num % 3 === 0) return false;
for (let i = 5; i * i <= num; i += 6) {
if (num % i === 0 || num % (i + 2) === 0) return false;
}
return true;
};
for (let i = 2; i <= limit; i++) {
if (isPrime(i)) {
primes.push(i);
}
}
const endTime = Date.now() - startTime
const response = {
statusCode: 200,
body: JSON.stringify({
executionTime: `${endTime} ms`,
isLambdaWarm: `${isLambdaWarm}`
}),
};
if (!isLambdaWarm) {
isLambdaWarm = true
}
return response;
};
Nach dem Login kopieren
Und für API-Tests verwenden wir den folgenden Code:
let isLambdaWarm = false
export async function handler(event) {
const url = event.url || 'https://jsonplaceholder.typicode.com/posts/1'
console.log('starting fetch url', { url })
const startTime = Date.now()
let resp;
try {
const response = await fetch(url)
const data = await response.json()
const endTime = Date.now() - startTime
resp = {
statusCode: 200,
body: JSON.stringify({
executionTime: `${endTime} ms`,
isLambdaWarm: `${isLambdaWarm}`
}),
}
}
catch (error) {
resp = {
statusCode: 500,
body: JSON.stringify({
message: 'Error fetching data',
error: error.message,
}),
}
}
if (!isLambdaWarm) {
isLambdaWarm = true
}
return resp;
};
Nach dem Login kopieren
Testergebnisse
Das Ziel ist hier eher lehrreich, daher besteht unsere Stichprobe für jeden Test aus 15 Warmstartdaten und 1 Kaltstartdaten.
Speicherverbrauch
LLRT JS – für beide Tests wurde die gleiche Menge an Speicher verbraucht: 23 MB.
NodeJS – für den Primzahltest begann NodeJS 69 MB zu verbrauchen und stieg auf 106 MB.
Für den API-Test betrug das Minimum 86 MB und das Maximum 106 MB.
Ausführungszeit
nach dem Entfernen der Ausreißer war das Ergebnis:
Abschlussbericht
Speicherverbrauch – Beim Speicherverbrauch wurde beobachtet, dass LLRT die verfügbaren Ressourcen im Vergleich zu nodejs besser nutzte.
Leistung – wir haben festgestellt, dass der Knoten im Hochverarbeitungsszenario eine viel höhere Leistung als LLRT beibehielt, sowohl beim Kaltstart als auch beim Warmstart.
Für das niedrigere Verarbeitungsszenario hatte LLRT einen gewissen Vorteil, insbesondere beim Kaltstart.
Warten wir dann auf die endgültigen Ergebnisse und hoffen wir, dass wir noch deutlichere Verbesserungen erzielen können, aber es ist großartig, die Flexibilität von JS zu sehen und zu sehen, wie viel es uns liefern kann und noch liefern muss.
Ich hoffe, es hat Ihnen gefallen und Ihnen geholfen, Ihr Verständnis für etwas zu verbessern oder Ihnen sogar Wege zu neuem Wissen zu eröffnen. Ich zähle auf Ihre Kritik und Anregungen, damit wir den Inhalt verbessern und ihn für die Community immer aktuell halten können.
Das obige ist der detaillierte Inhalt vonLamba LLRT. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
