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. # .NET-Laufzeit für verwaltete Lambda-Instanzen Für .NET-Laufzeiten verwenden Lambda Managed Instances einen einzigen .NET-Prozess pro Ausführungsumgebung. Mithilfe von.NET-Aufgaben werden mehrere Anfragen gleichzeitig verarbeitet. ## Konfiguration der Parallelität Die maximale Anzahl gleichzeitiger Anfragen, die Lambda an jede Ausführungsumgebung sendet, wird durch die `PerExecutionEnvironmentMaxConcurrency` Einstellung in der Funktionskonfiguration gesteuert. Dies ist eine optionale Einstellung, und der Standardwert variiert je nach Laufzeit. Für .NET-Laufzeiten ist die Standardeinstellung 32 gleichzeitige Anfragen pro vCPU, oder Sie können Ihren eigenen Wert konfigurieren. Lambda passt die Anzahl der gleichzeitigen Anfragen automatisch bis zum konfigurierten Maximum an, basierend auf der Kapazität jeder Ausführungsumgebung, um diese Anfragen aufzunehmen. ## Erstellung von Funktionen für Mehrfachparallelität Sie sollten bei der Verwendung von Lambda Managed Instances dieselben Sicherheitspraktiken für Parallelität anwenden wie in jeder anderen Umgebung mit mehreren gleichzeitigen Vorgängen. Da das Handler-Objekt von allen Tasks gemeinsam genutzt wird, muss jeder veränderbare Status Thread-sicher sein. Dazu gehören Sammlungen, Datenbankverbindungen und alle statischen Objekte, die während der Anforderungsverarbeitung geändert werden. AWS SDK-Clients sind Thread-sicher und erfordern keine besondere Behandlung. **Beispiel: Datenbank-Verbindungspools** Der folgende Code verwendet ein statisches Datenbankverbindungsobjekt, das von mehreren gleichzeitigen Anfragen gemeinsam genutzt wird. Das `SqlConnection` Objekt ist nicht threadsicher. ``` public class DBQueryHandler { // Single connection shared across threads - NOT SAFE private SqlConnection connection; public DBQueryHandler() { connection = new SqlConnection("your-connection-string-here"); connection.Open(); } public string Handle(object input, ILambdaContext context) { using var cmd = connection.CreateCommand(); cmd.CommandText = "SELECT ..."; // your query using var reader = cmd.ExecuteReader(); ... } } ``` Um dieses Problem zu lösen, verwenden Sie für jede Anfrage eine separate Verbindung, die aus einem Verbindungspool stammt. ADO.NET-Anbieter unterstützen beispielsweise `Microsoft.Data.SqlClient` automatisch das Verbindungspooling, wenn das Verbindungsobjekt geöffnet wird. ``` public class DBQueryHandler { public DBQueryHandler() { } public string Handle(object input, ILambdaContext context) { using var connection = new SqlConnection("your-connection-string-here"); connection.Open(); using var cmd = connection.CreateCommand(); cmd.CommandText = "SELECT ..."; // your query using var reader = cmd.ExecuteReader(); ... } } ``` **Beispiel: Sammlungen** Standard-.NET-Sammlungen sind nicht threadsicher: ``` public class Handler { private static List items = new List(); private static Dictionary cache = new Dictionary(); public string FunctionHandler(object input, ILambdaContext context) { items.Add(context.AwsRequestId); cache["key"] = input; return "Success"; } } ``` Verwenden Sie aus Sicherheitsgründen Sammlungen aus dem `System.Collections.Concurrent` Namespace: ``` public class Handler { private static ConcurrentBag items = new ConcurrentBag(); private static ConcurrentDictionary cache = new ConcurrentDictionary(); public string FunctionHandler(object input, ILambdaContext context) { items.Add(context.AwsRequestId); cache["key"] = input; return "Success"; } } ``` ## Gemeinsames /tmp-Verzeichnis Das `/tmp` Verzeichnis wird von allen gleichzeitigen Anfragen in der Ausführungsumgebung gemeinsam genutzt. Gleichzeitige Schreibvorgänge in dieselbe Datei können zu Datenbeschädigungen führen, z. B. wenn eine andere Anforderung die Datei überschreibt. Um dieses Problem zu lösen, implementieren Sie entweder Dateisperren für gemeinsam genutzte Dateien oder verwenden Sie eindeutige Dateinamen pro Anfrage, um Konflikte zu vermeiden. Denken Sie daran, nicht benötigte Dateien zu bereinigen, um zu vermeiden, dass der verfügbare Speicherplatz aufgebraucht wird. ## Protokollierung Das Verschachteln von Protokollen (Protokolleinträge verschiedener Anfragen, die in Protokollen verschachtelt werden) ist bei Systemen mit mehreren gleichzeitigen Vorgängen normal. Funktionen, die Lambda Managed Instances verwenden, verwenden immer das strukturierte JSON-Protokollformat, das mit [erweiterten Protokollierungssteuerungen](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) eingeführt wurde. Dieses Format beinhaltet die`requestId`, sodass Protokolleinträge mit einer einzigen Anfrage korreliert werden können. Wenn Sie das `context.Logger` Objekt zum Generieren von Protokollen verwenden, `requestId` wird es automatisch in jeden Protokolleintrag aufgenommen. Weitere Informationen finden Sie unter[Verwenden von Lambda-Optionen für die erweiterte Protokollierung mit .NET](csharp-logging.md#csharp-logging-advanced). ## Kontext anfordern Verwenden Sie die `context.AwsRequestId` Eigenschaft, um auf die Anforderungs-ID für die aktuelle Anfrage zuzugreifen. Verwenden Sie die `context.TraceId` Eigenschaft, um auf die X-Ray-Trace-ID zuzugreifen. Dies ermöglicht einen parallelen Zugriff auf die Trace-ID für die aktuelle Anfrage. Lambda unterstützt die `_X_AMZN_TRACE_ID` Umgebungsvariable bei Lambda Managed Instances nicht. Die X-Ray-Trace-ID wird bei Verwendung des AWS SDK automatisch weitergegeben. Wird verwendet`ILambdaContext.RemainingTime`, um Timeouts zu erkennen. Weitere Informationen finden Sie unter [Fehlerbehandlung und Wiederherstellung](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling). ## Initialisierung und Herunterfahren Die Funktionsinitialisierung erfolgt einmal pro Ausführungsumgebung. Objekte, die während der Initialisierung erstellt wurden, werden von allen Anfragen gemeinsam genutzt. Bei Lambda-Funktionen mit Erweiterungen gibt die Ausführungsumgebung beim Herunterfahren ein SIGTERM-Signal aus. Dieses Signal wird von Erweiterungen verwendet, um Bereinigungsaufgaben wie das Leeren von Puffern auszulösen. Sie können SIGTERM-Ereignisse abonnieren, um Aufgaben zur Funktionsbereinigung auszulösen, z. B. das Schließen von Datenbankverbindungen. Weitere Informationen zum Lebenszyklus der Ausführungsumgebung finden Sie unter [Verständnis des Lebenszyklus der Lambda-Ausführungsumgebung](lambda-runtime-environment.md). ## Versionen von Abhängigkeiten Für Lambda Managed Instances sind die folgenden Mindestpaketversionen erforderlich: + Amazon.Lambda.Core: Version 2.7.1 oder höher + Amazon.Lambda. RuntimeSupport: Version 1.14.1 oder höher + OpenTelemetry. Instrumentierung. AWSLambda: Version 1.14.0 oder höher + AWSXRayRecorder.Core: Version 2.16.0 oder höher + AWSSDK.Core: Version 4.0.0.32 oder höher ## Powertools für AWS Lambda (.NET) [Powertools for AWS Lambda (.NET)](https://docs.aws.amazon.com/powertools/dotnet/) und [AWS Distro for OpenTelemetry - Instrumentation for](https://github.com/aws-observability/aws-otel-dotnet-instrumentation) unterstützen DotNet derzeit keine Lambda Managed Instances. ## Nächste Schritte + Überprüfen Sie die [Java-Laufzeit für Lambda Managed Instances](lambda-managed-instances-java-runtime.md) + Überprüfen Sie die [Laufzeit von Node.js für Lambda Managed Instances](lambda-managed-instances-nodejs-runtime.md) + Überprüfen Sie die [Python-Laufzeit für Lambda Managed Instances](lambda-managed-instances-python-runtime.md) + Erfahren Sie mehr über die [Skalierung von Lambda Managed Instances](lambda-managed-instances-scaling.md)