Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Laufzeiten der Lambda-Webfunktion
Lambda Web Functions führen Ihren HTTP-Servercode mithilfe verwalteter Laufzeiten aus. Ihre Anwendung muss einen HTTP-Server starten, der den in der Umgebungsvariablen angegebenen Host und Port überwacht. `AWS_LAMBDA_HTTP_ENDPOINT` Lambda-Webfunktionen werden derzeit unterstütztNode.js. Standardmäßig wird die Runtime `index.js` im Stammverzeichnis des Bereitstellungspakets geladen. Um eine andere Eintragsdatei zu verwenden, legen Sie die `AWS_LAMBDA_NODEJS_ENTRYPOINT` Umgebungsvariable fest. Details hierzu finden Sie unter [Umgebungsvariablen](web-functions-revisions-env-vars.md).
## Unterstützt Node.js Versionen
| Laufzeit-ID | Node.js-Version | Status |
| --- | --- | --- |
| nodejs24.x | Node.js24 | Unterstützt |
Geben Sie die Laufzeit-ID in dem `runtimeConfig` Abschnitt an, wenn Sie eine Revision erstellen. Beispiel:
```
"runtimeConfig": { "runtime": "nodejs24.x" }
```
Die `nodejs24.x` Web Function-Laufzeit folgt demselben Verfallszyklus wie die entsprechende Lambda Event Functions-Laufzeit. Informationen zu den Verfallsdaten und zum Ablauf der Verwarnung finden Sie unter. [Richtlinie für den Laufzeitablauf](lambda-runtimes.md#runtime-support-policy)
## Automatisches Runtime-Patching
Lambda patcht die Node.js Laufzeit automatisch mit Sicherheitsupdates und Bugfixes. Das Patchen bezieht sich auf die zugrunde liegende Laufzeitebene und ändert Ihren Anwendungscode nicht. Die `runtime` ID Ihrer Revision (z. B.`nodejs24.x`) entspricht immer der neuesten gepatchten Version dieser Haupt-Runtime.
**Anmerkung**
Steuerelemente zur Laufzeitverwaltung werden für Webfunktionen nicht unterstützt. Sie können sich nicht an eine bestimmte Patch-Version binden oder das automatische Patchen deaktivieren. Lambda verwendet immer die neueste gepatchte Version der Laufzeit, die Sie angegeben haben.
Weitere Informationen darüber, wie Lambda Runtime-Updates verwaltet, finden Sie unter[Verstehen, wie Lambda Laufzeit-Versionsupdates verwaltet](runtimes-update.md).
## Unterstützte Web-Frameworks
Sie können jedes Node.js Web-Framework verwenden, das einen HTTP-Server startet. Zu den beliebten Frameworks gehören:
+ Express
+ Next.js
+ Fastify
+ Koa
Sie benötigen den AWS Lambda Web Adapter oder einen anderen Event-zu-HTTP-Adapter nicht. Ihre Anwendung verarbeitet HTTP-Anfragen direkt mithilfe des Standard-Routing und der Middleware des Frameworks. Einige Frameworks, z. B. Next.js im Standalone-Modus, lesen ihre eigenen Umgebungsvariablen für die Listen-Adresse. Verwenden Sie für diese Frameworks eine `index.js` Eintragsdatei, die diese Variablen festlegt, `AWS_LAMBDA_HTTP_ENDPOINT` bevor der Server gestartet wird. Details hierzu finden Sie unter [Umgebungsvariablen](web-functions-revisions-env-vars.md). Eine vollständige Anwendung finden Sie unter[Minimal Express Anwendung](web-functions-samples.md#web-functions-samples-express).
## Node.js Ausführungsmodell
Node.jsverwendet ein ereignisgesteuertes Ausführungsmodell. Node.jsFührt Ihren JavaScript Code standardmäßig in einem einzigen Haupt-Thread aus, und I/O Operationen (Netzwerkaufrufe, Dateisystemzugriff) sind nicht blockierend und ereignisgesteuert. Ihre Anwendung kann bei Bedarf zusätzliche Threads mit dem `worker_threads` Modul erstellen. Dieses Modell hat wichtige Auswirkungen auf Webfunktionen:
**Parallelität durch Async I/O**
Ihr Server verarbeitet mehrere gleichzeitige Anfragen mithilfe asynchroner Operationen (`async`/`await`, Promises, Callbacks). Während eine Anfrage auf eine Datenbankantwort wartet, bedient die Event-Schleife andere Anfragen. Aus diesem Grund können Web Functions viele gleichzeitige Anfragen in einer einzigen Umgebung ohne mehrere Threads verarbeiten.
**Vermeiden Sie es, die Ereignisschleife zu blockieren**
CPU-intensive synchrone Operationen (umfangreiche JSON-Analyse, komplexe Berechnungen, synchrone Dateilesevorgänge) blockieren die Ereignisschleife und verhindern, dass alle anderen Anfragen verarbeitet werden. Wenn Ihre Anwendung CPU-heavy Arbeit verrichtet, verlagern Sie sie auf Worker-Threads oder reduzieren `maxConcurrencyPerEnvironment` Sie sie, um die Auswirkungen zu begrenzen.
**Isolierung beantragen**
Da alle Anfragen denselben Prozess und dieselbe Ereignisschleife verwenden, sollten Sie vermeiden, den Status pro Anfrage in globalen Variablen zu speichern. Verwenden Sie einen Middleware-Kontext, der sich auf Anfragen bezieht (z. B. Express `req` `res` /objects), um Anforderungsdaten zu isolieren.
Hinweise zur Konfiguration auf der `maxConcurrencyPerEnvironment` Grundlage Ihrer Anwendungs- und CPU-Eigenschaften finden Sie unter. I/O [Skalierungsverhalten für Lambda Web Functions](web-functions-scaling.md)
## Speicher und Node.js Haufen
Jede Ausführungsumgebung hat 2 GB Arbeitsspeicher. Für den Node.js V8-Heap gilt Folgendes:
+ Der Standard-Heap ist 1.024 MB groß.
+ Um einen größeren Heap zu verwenden, geben Sie `NODE_OPTIONS` beispielsweise die Umgebungsvariablen der Revision ein `NODE_OPTIONS=--max-old-space-size=1536` (der Wert ist in MB angegeben).
+ Ein Wert, den Sie eingegeben haben, `NODE_OPTIONS` ersetzt den Standardwert. Wenn Sie nur festlegen`--max-old-space-size`, legt Lambda nichts fest `--max-semi-space-size` und Node.js verwendet dafür seine eigene Standardeinstellung.
+ Der Heap, die Puffer, die systemeigenen Zuweisungen, die Laufzeit und die gleichzeitigen Anfragen müssen alle in den 2 GB Umgebungsspeicher passen.
## So leitet Lambda Anfragen an Ihre Anwendung weiter
Webfunktions-Endpunkte akzeptieren nur HTTPS-Verkehr auf Port 443. Klares HTTP wird nicht bereitgestellt, sodass Sie HTTP nicht zu HTTPS umleiten oder TLS in Ihrer Anwendung konfigurieren müssen.
Lambda beendet TLS am Endpunkt und leitet jede Anfrage an den HTTP-Server Ihrer Anwendung innerhalb der Ausführungsumgebung weiter. Ihre Anwendung stellt reines HTTP an der Adresse bereit, die Lambda bereitstellt. Sie verarbeiten in Ihrem Code niemals Zertifikate oder TLS-Konfigurationen.
Lambda wählt den Host und den Port aus, auf die Ihr Server warten muss. Lambda übermittelt Ihrer Anwendung die Adresse über die `AWS_LAMBDA_HTTP_ENDPOINT` Umgebungsvariable im `host:port` Format. Verwenden Sie diese Variable, die Lambda festlegt, um zu bestimmen, wo Ihr Server lauscht. Ihre Anwendung muss die Variable beim Start lesen:
```
const [host, port] = (process.env.AWS_LAMBDA_HTTP_ENDPOINT || 'localhost:3000').split(':');
app.listen(port, host);
```
Lambda legt die Variable nicht auf Ihrem lokalen Computer fest. Die Fallback-Adresse gilt nur, wenn die Variable nicht gesetzt ist, sodass sie nur in lokalen Läufen verwendet wird. Wenn Sie eine andere lokale Adresse verwenden möchten, legen Sie diese selbst fest`AWS_LAMBDA_HTTP_ENDPOINT`. Ein Beispiel finden Sie unter [Führen Sie den HTTP-Server lokal aus](web-functions-testing.md#web-functions-testing-local).
Lambda fügt jeder Anfrage, die es an Ihre Anwendung weiterleitet, einen `lambda-web-request-id` Header hinzu und gibt denselben Wert wie ein Antwortheader zurück, sodass Sie eine Client-Anfrage mit Ihren Anwendungsprotokollen korrelieren können.
Lambda leitet Webanfragen an die von `AWS_LAMBDA_HTTP_ENDPOINT` angegebene Adresse weiter. Wenn Ihr Server auf einem anderen Host oder Port lauscht, erreichen Anfragen Ihre Anwendung nicht.
Ihr Server muss innerhalb von 10 Sekunden nach dem Start mit der Überwachung beginnen, und jede Anfrage, die er bearbeitet, ist an die `timeoutSeconds` Einstellung der Revision gebunden. Informationen zur Reihenfolge beim Starten und Herunterfahren finden Sie unter[Lebenszyklus der Ausführungsumgebung](web-functions-env-lifecycle.md). Informationen zur Konfiguration finden `timeoutSeconds` Sie unter[Revisionen von Webfunktionen verwalten](web-functions-revisions.md).