Warnung: 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, es zu verbessern :)

Haben Sie jemals darüber nachgedacht, dass die Anforderungen an die Leistung unserer Anwendungen immer größer werden?
Jeden Tag stehen wir vor der Herausforderung, sie schneller zu machen, und damit 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 bis zu 2-mal niedrigere Gesamtkosten 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.

Sehen Sie, dass sie darauf abzielen, etwas zu liefern, das bis zu zehnmal 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 im Code selbst eingespart.

Aber keine Sorge, nicht alles ist rosig, es sind Kompromisse (schreckliches Wortspiel, ich weiß, lol).
Daher müssen einige wichtige Punkte berücksichtigt 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 deutliche Leistungseinbußen aufweist, wie etwa 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, sind für den Übergang zurück zu alternativen Lösungen nur minimale Codeanpassungen erforderlich.

Darüber hinaus ist die Idee, dass LLRT JS kein Ersatz für node.js ist und es auch nie sein wird.

Sehen:

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 packen Sie es an...

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 



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;
};






  
  
  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 Szenario mit hoher Verarbeitung sowohl beim Kaltstart als auch beim Warmstart eine viel bessere Leistung aufwies als LLRT.

Für das niedrigere Verarbeitungsszenario hatte LLRT einen gewissen Vorteil, insbesondere beim Kaltstart.

Warten wir 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 leisten 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.