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<string> items = new List<string>();
    private static Dictionary<string, object> cache = new Dictionary<string, object>();

    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<string> items = new ConcurrentBag<string>();
    private static ConcurrentDictionary<string, object> cache = new ConcurrentDictionary<string, object>();

    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 eingeführt wurde. Dieses Format beinhaltet dierequestId, 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 Erweiterte Lambda-Protokollierungssteuerelemente mit .NET verwenden.

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.

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 Grundlegendes zum Lebenszyklus der Lambda-Ausführungsumgebung.

Versionen von Abhängigkeiten

Lambda Managed Instances erfordert die folgenden Mindestpaketversionen:

Powertools für AWS Lambda (.NET)

Powertools for AWS Lambda (.NET) und AWS Distro for OpenTelemetry - Instrumentation for unterstützen DotNet derzeit keine Lambda Managed Instances.

Nächste Schritte