Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Environnement d'exécution .NET pour les instances gérées Lambda Pour les environnements d'exécution .NET, les instances gérées Lambda utilisent un seul processus .NET par environnement d'exécution. Plusieurs demandes simultanées sont traitées à l'aide de tâches .NET. ## Configuration de la simultanéité Le nombre maximum de demandes simultanées que Lambda envoie à chaque environnement d'exécution est contrôlé par le `PerExecutionEnvironmentMaxConcurrency` paramètre de configuration de la fonction. Il s'agit d'un paramètre facultatif, et la valeur par défaut varie en fonction du temps d'exécution. Pour les environnements d'exécution .NET, la valeur par défaut est de 32 requêtes simultanées par vCPU, ou vous pouvez configurer votre propre valeur. Lambda ajuste automatiquement le nombre de demandes simultanées jusqu'au maximum configuré en fonction de la capacité de chaque environnement d'exécution à absorber ces demandes. ## Création de fonctions pour la multisimultanéité Lorsque vous utilisez des instances gérées Lambda, vous devez appliquer les mêmes pratiques de sécurité en matière de simultanéité que dans tout autre environnement multiconcurrent. Étant donné que l'objet du gestionnaire est partagé entre toutes les tâches, tout état mutable doit être adapté aux threads. Cela inclut les collections, les connexions aux bases de données et tous les objets statiques modifiés lors du traitement des demandes. AWS Les clients du SDK sont compatibles avec les threads et ne nécessitent aucune manipulation particulière. **Exemple : pools de connexions aux bases de données** Le code suivant utilise un objet de connexion à une base de données statique qui est partagé entre des demandes simultanées. L'`SqlConnection`objet n'est pas compatible avec les threads. ``` 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(); ... } } ``` Pour résoudre ce problème, utilisez une connexion distincte pour chaque demande, issue d'un pool de connexions. Les fournisseurs ADO.NET prennent en charge `Microsoft.Data.SqlClient` automatiquement le regroupement de connexions lorsque l'objet de connexion est ouvert. ``` 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(); ... } } ``` **Exemple : Collections** Les collections .NET standard ne sont pas adaptées aux threads : ``` 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"; } } ``` Utilisez les collections de l'espace de `System.Collections.Concurrent` noms pour des raisons de sécurité en matière de concurrence : ``` 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"; } } ``` ## Répertoire /tmp partagé Le `/tmp` répertoire est partagé entre toutes les demandes simultanées dans l'environnement d'exécution. Les écritures simultanées dans le même fichier peuvent entraîner une corruption des données, par exemple si une autre demande remplace le fichier. Pour résoudre ce problème, implémentez le verrouillage des fichiers partagés ou utilisez des noms de fichiers uniques par demande afin d'éviter les conflits. N'oubliez pas de nettoyer les fichiers inutiles pour ne pas épuiser l'espace disponible. ## Logging L'entrelacement des journaux (les entrées des journaux provenant de différentes demandes sont entrelacées dans des journaux) est normal dans les systèmes multiconcurrents. Les fonctions utilisant des instances gérées Lambda utilisent toujours le format de journal JSON structuré introduit avec les contrôles de [journalisation avancés](monitoring-logs.md#monitoring-cloudwatchlogs-advanced). Ce format inclut le`requestId`, ce qui permet de corréler les entrées du journal à une seule demande. Lorsque vous utilisez l'`context.Logger`objet pour générer des journaux, ceux-ci `requestId` sont automatiquement inclus dans chaque entrée de journal. Pour de plus amples informations, voir[Utilisation des contrôles de journalisation avancés de Lambda avec .NET](csharp-logging.md#csharp-logging-advanced). ## Contexte de la requête Utilisez la `context.AwsRequestId` propriété pour accéder à l'ID de demande pour la demande en cours. Utilisez la `context.TraceId` propriété pour accéder au X-Ray Trace ID. Cela fournit un accès simultané à l'ID de trace pour la demande en cours. Lambda ne prend pas en charge la variable d'`_X_AMZN_TRACE_ID`environnement avec les instances gérées par Lambda. Le X-Ray Trace ID est automatiquement propagé lors de l'utilisation du AWS SDK. `ILambdaContext.RemainingTime`À utiliser pour détecter les délais d'expiration. Pour plus d’informations, consultez [Gestion des erreurs et restauration](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling). ## Initialisation et arrêt L'initialisation de la fonction a lieu une fois par environnement d'exécution. Les objets créés lors de l'initialisation sont partagés entre les demandes. Pour les fonctions Lambda avec extensions, l'environnement d'exécution émet un signal SIGTERM lors de l'arrêt. Ce signal est utilisé par les extensions pour déclencher des tâches de nettoyage, telles que le vidage des tampons. Vous pouvez vous abonner aux événements SIGTERM pour déclencher des tâches de nettoyage des fonctions, telles que la fermeture des connexions aux bases de données. Pour en savoir plus sur le cycle de vie de l'environnement d'exécution, veuillez consulter [Comprendre le cycle de vie de l’environnement d’exécution Lambda](lambda-runtime-environment.md). ## Versions de dépendance Les instances gérées Lambda nécessitent les versions de package minimales suivantes : + Amazon.Lambda.Core : version 2.7.1 ou ultérieure + Amazon Lambda. RuntimeSupport: version 1.14.1 ou ultérieure + OpenTelemetry.Instrumentation. AWSLambda: version 1.14.0 ou ultérieure + AWSXRayRecorder.Core : version 2.16.0 ou ultérieure + AWSSDK.Core : version 4.0.0.32 ou ultérieure ## Outils électriques pour AWS Lambda (.NET) [Powertools for AWS Lambda (.NET](https://docs.aws.amazon.com/powertools/dotnet/)) [AWS et Distro OpenTelemetry for - Instrumentation DotNet for](https://github.com/aws-observability/aws-otel-dotnet-instrumentation) ne prennent actuellement pas en charge les instances gérées par Lambda. ## Étapes suivantes + Passez en revue l'[environnement d'exécution Java pour les instances gérées Lambda](lambda-managed-instances-java-runtime.md) + Passez en revue [le runtime Node.js pour les instances gérées Lambda](lambda-managed-instances-nodejs-runtime.md) + Passez [en revue le runtime Python pour les instances gérées Lambda](lambda-managed-instances-python-runtime.md) + En savoir plus sur le [dimensionnement des instances gérées Lambda](lambda-managed-instances-scaling.md)