Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
.NET runtime per istanze gestite Lambda
Per i runtime.NET, le istanze gestite Lambda utilizzano un singolo processo.NET per ambiente di esecuzione. Più richieste simultanee vengono elaborate utilizzando .NET Tasks.
Configurazione della concorrenza
Il numero massimo di richieste simultanee che Lambda invia a ciascun ambiente di esecuzione è controllato dall'impostazione nella configurazione PerExecutionEnvironmentMaxConcurrency della funzione. Questa è un'impostazione opzionale e il valore predefinito varia a seconda del runtime. Per i runtime.NET, l'impostazione predefinita è 32 richieste simultanee per vCPU, oppure è possibile configurare un valore personalizzato. Lambda regola automaticamente il numero di richieste simultanee fino al massimo configurato in base alla capacità di ciascun ambiente di esecuzione di assorbire tali richieste.
Creazione di funzioni per la multiconcorrenza
È necessario applicare le stesse pratiche di sicurezza della concorrenza quando si utilizzano le istanze gestite Lambda come si farebbe in qualsiasi altro ambiente multi-concorrente. Poiché l'oggetto handler è condiviso tra tutte le attività, qualsiasi stato mutabile deve essere thread-safe. Ciò include raccolte, connessioni al database e qualsiasi oggetto statico modificato durante l'elaborazione della richiesta.
AWS I client SDK sono thread-safe e non richiedono una gestione speciale.
Esempio: pool di connessioni al database
Il codice seguente utilizza un oggetto di connessione statico al database condiviso tra richieste simultanee. L'SqlConnectionoggetto non è thread-safe.
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(); ... } }
Per risolvere questo problema, utilizzate una connessione separata per ogni richiesta, ricavata da un pool di connessioni. ADO.NET ad esempio, i provider supportano Microsoft.Data.SqlClient automaticamente il pool di connessioni quando l'oggetto di connessione viene aperto.
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(); ... } }
Esempio: collezioni
Le raccolte .NET standard non sono thread-safe:
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"; } }
Usa le raccolte dallo spazio dei System.Collections.Concurrent nomi per la sicurezza della concorrenza:
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"; } }
Directory /tmp condivisa
La /tmp directory è condivisa tra tutte le richieste simultanee nell'ambiente di esecuzione. Le scritture simultanee sullo stesso file possono causare il danneggiamento dei dati, ad esempio se un'altra richiesta sovrascrive il file. Per risolvere questo problema, implementate il blocco dei file per i file condivisi o utilizzate nomi di file univoci per richiesta per evitare conflitti. Ricordati di ripulire i file non necessari per evitare di esaurire lo spazio disponibile.
Registrazione dei log
L'interlacciamento dei log (le voci di registro di diverse richieste vengono interlacciate nei log) è normale nei sistemi multi-concorrenti. Le funzioni che utilizzano Lambda Managed Instances utilizzano sempre il formato di registro JSON strutturato introdotto con controlli di registrazione avanzati. Questo formato includerequestId, che consente di correlare le voci di registro a una singola richiesta. Quando si utilizza l'context.Loggeroggetto per generare registri, requestId viene automaticamente incluso in ogni voce di registro. Per ulteriori informazioni, vedereUtilizzo dei controlli di registrazione avanzati di Lambda con .NET.
Contesto della richiesta
Utilizza la context.AwsRequestId proprietà per accedere all'ID della richiesta corrente.
Utilizzate la context.TraceId proprietà per accedere all'ID di X-Ray traccia. Ciò fornisce un accesso sicuro per la concorrenza all'ID di traccia per la richiesta corrente. Lambda non supporta la variabile di _X_AMZN_TRACE_ID ambiente con Lambda Managed Instances. L'ID di X-Ray traccia viene propagato automaticamente quando si utilizza l'SDK. AWS
Utilizzato ILambdaContext.RemainingTime per rilevare i timeout. Per ulteriori informazioni, consulta Gestione e ripristino degli errori.
Esempio: gestione dei timeout
Controlla il tempo rimanente prima di ogni unità di lavoro e interrompi l'elaborazione prima che scada il timeout. Configura il buffer in base alla durata prevista della prossima parte di lavoro.
private static readonly TimeSpan Buffer = TimeSpan.FromMilliseconds(2000); public APIGatewayProxyResponse FunctionHandler(APIGatewayProxyRequest request, ILambdaContext context) { var items = JsonSerializer.Deserialize<List<string>>(request.Body); foreach (var item in items) { if (context.RemainingTime < Buffer) return new APIGatewayProxyResponse { StatusCode = 206, Body = "Timeout approaching, stopping early" }; ProcessItem(item); } return new APIGatewayProxyResponse { StatusCode = 200, Body = "Done" }; }
Esempio: propagazione delle scadenze alle chiamate downstream
Quando effettui chiamate ai servizi downstream, propaga il tempo rimanente come timeout per evitare di dover affrontare chiamate di rete che potrebbero durare più a lungo della chiamata. Usa a CancellationToken con un client condiviso anziché creare un nuovo client per chiamata:
using Amazon.S3; private static readonly IAmazonS3 s3 = new AmazonS3Client(); public async Task<string> FunctionHandler(APIGatewayProxyRequest request, ILambdaContext context) { var timeout = context.RemainingTime - TimeSpan.FromMilliseconds(500); if (timeout < TimeSpan.FromSeconds(1)) timeout = TimeSpan.FromSeconds(1); using var cts = new CancellationTokenSource(timeout); await s3.GetObjectAsync("my-bucket", "my-key", cts.Token); return "Done"; }
Inizializzazione e spegnimento
L'inizializzazione della funzione avviene una volta per ambiente di esecuzione. Gli oggetti creati durante l'inizializzazione vengono condivisi tra le richieste.
Per le funzioni Lambda con estensioni, l'ambiente di esecuzione emette un segnale SIGTERM durante lo spegnimento. Questo segnale viene utilizzato dalle estensioni per attivare attività di pulizia, come lo svuotamento dei buffer. È possibile sottoscrivere eventi SIGTERM per attivare attività di pulizia delle funzioni, come la chiusura delle connessioni al database. Per ulteriori informazioni sul ciclo di vita dell'ambiente di esecuzione, consulta Comprendere il ciclo di vita dell’ambiente di esecuzione Lambda.
Versioni di dipendenza
Lambda Managed Instances richiede le seguenti versioni minime del pacchetto:
-
Amazon.Lambda.Core: versione 2.7.1 o successiva
-
Amazon.Lambda.RuntimeSupport: versione 1.14.1 o successiva
-
OpenTelemetry.Instrumentation.AWSLambda: versione 1.14.0 o successiva
-
AWSXRayRecorder.Core: versione 2.16.0 o successiva
-
AWSSDK.Core: versione 4.0.0.32 o successiva
Utensili elettrici per AWS Lambda (.NET)
Powertools for AWS Lambda (.NET) AWS e Distro OpenTelemetry for - Instrumentation for DotNet