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à.
# Runtime Node.js per istanze gestite Lambda
Per i runtime di Node.js, Lambda Managed Instances utilizza thread di lavoro `async` con esecuzione basata su`await`/per gestire le richieste simultanee. L'inizializzazione della funzione avviene una volta per thread di lavoro. Le chiamate simultanee vengono gestite in due dimensioni: i thread di lavoro forniscono il parallelismo su v e l'esecuzione asincrona fornisce la concorrenza all'interno di CPUs ciascun thread. Ogni richiesta concorrente gestita dallo stesso thread di lavoro condivide lo stesso oggetto del gestore e lo stesso stato globale, il che richiede una gestione sicura in caso di più richieste simultanee.
## Simultaneità massima
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 di Node.js, l'impostazione predefinita è 64 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.
Per Node.js, il numero di richieste simultanee che ogni ambiente di esecuzione può elaborare è determinato dal numero di thread di lavoro e dalla capacità di ciascun thread di lavoro di elaborare le richieste concorrenti in modo asincrono. Il numero predefinito di thread di lavoro è determinato dal numero di v CPUs disponibili oppure è possibile configurare il numero di thread di lavoro impostando la variabile di ambiente. `AWS_LAMBDA_NODEJS_WORKER_COUNT` Si consiglia di utilizzare gestori di funzioni asincroni poiché ciò consente l'elaborazione di più richieste per thread di lavoro. Se il gestore di funzioni è sincrono, ogni thread di lavoro può elaborare solo una singola richiesta alla volta.
## Creazione di funzioni per la concorrenza multipla
Con un gestore di funzioni asincrone, ogni runtime worker elabora più richieste contemporaneamente. Gli oggetti globali verranno condivisi tra più richieste simultanee. Per gli oggetti mutabili, evita di usare global state or use. `AsyncLocalStorage`
AWS I client SDK sono asincroni e non richiedono una gestione speciale.
**Esempio: stato globale**
Il codice seguente utilizza un oggetto globale che viene modificato all'interno del gestore della funzione. Questo non è asincrono.
```
let state = {
currentUser: null,
requestData: null
};
export const handler = async (event, context) => {
state.currentUser = event.userId;
state.requestData = event.data;
await processData(state.requestData);
// state.currentUser might now belong to a different request
return { user: state.currentUser };
};
```
L'inizializzazione dell'`state`oggetto all'interno del gestore della funzione evita lo stato globale condiviso.
```
export const handler = async (event, context) => {
let state = {
currentUser: event.userId,
requestData: event.data
};
await processData(state.requestData);
return { user: state.currentUser };
};
```
**Esempio: connessioni al database**
Il codice seguente utilizza un oggetto client condiviso che viene condiviso tra più chiamate. A seconda della libreria di connessioni utilizzata, questo potrebbe non essere sicuro in termini di concorrenza.
```
const { Client } = require('pg');
// Single connection created at init time
const client = new Client({
host: process.env.DB_HOST,
database: process.env.DB_NAME,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD
});
// Connect once during cold start
client.connect();
exports.handler = async (event) => {
// Multiple parallel invocations share this single connection = BAD
// With multi-concurrent Lambda, queries will collide
const result = await client.query('SELECT * FROM users WHERE id = $1', [event.userId]);
return {
statusCode: 200,
body: JSON.stringify(result.rows[0])
};
};
```
Un approccio sicuro per la concorrenza consiste nell'utilizzare un pool di connessioni. Il pool utilizza una connessione separata per ogni interrogazione simultanea del database.
```
const { Pool } = require('pg');
// Connection pool created at init time
const pool = new Pool({
host: process.env.DB_HOST,
database: process.env.DB_NAME,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD,
max: 20, // Max connections in pool
idleTimeoutMillis: 30000,
connectionTimeoutMillis: 2000
});
exports.handler = async (event) => {
// Pool gives each parallel invocation its own connection
const result = await pool.query('SELECT * FROM users WHERE id = $1', [event.userId]);
return {
statusCode: 200,
body: JSON.stringify(result.rows[0])
};
};
```
## Gestori basati su callback Node.js 22
Quando si utilizza Node.js 22, non è possibile utilizzare un gestore di funzioni basato su callback con Lambda Managed Instances. I gestori basati su callback sono supportati solo per le funzioni Lambda (predefinite). Per i runtime di Node.js 24 e versioni successive, i gestori di funzioni basati su callback sono obsoleti sia per le istanze gestite Lambda (impostazione predefinita) che per quelle gestite Lambda.
Utilizza invece un gestore di `async` funzioni quando usi Lambda Managed Instances. Per ulteriori informazioni, consulta [Definire il gestore di funzioni Lambda](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html) in Node.js.
## 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 altro processo 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.](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) Questo formato include`requestId`, che consente di correlare le voci di registro a una singola richiesta. Quando si utilizza il `console` logger, `requestId` viene automaticamente incluso in ogni voce di registro. Per ulteriori informazioni, vedere[Utilizzo dei controlli di registrazione avanzati di Lambda con Node.js](nodejs-logging.md#node-js-logging-advanced).
Le librerie di registrazione di terze parti più diffuse, come [Winston](https://github.com/winstonjs/winston), includono in genere il supporto per l'utilizzo della console per l'output dei log.
## Contesto della richiesta
Using `context.awsRequestId` fornisce un accesso sicuro e asincrono all'ID della richiesta corrente.
Utilizzare `context.xRayTraceId` per accedere all'ID di traccia X-Ray. Ciò fornisce un accesso sicuro in termini di 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 traccia X-Ray viene propagato automaticamente quando si utilizza l'SDK. AWS
Utilizzato per rilevare i `context.getRemainingTimeInMillis()` timeout. Per ulteriori informazioni, consulta [Gestione e ripristino degli errori](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
## Inizializzazione e spegnimento
L'inizializzazione della funzione avviene una volta per thread di lavoro. È possibile che vengano visualizzate voci di registro ripetute se la funzione emette log durante l'inizializzazione.
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. Le funzioni Lambda (impostazione predefinita) con estensioni possono anche sottoscrivere il segnale SIGTERM utilizzando. `process.on()` Questa funzionalità non è supportata per le funzioni che utilizzano istanze gestite Lambda poiché `process.on()` non può essere utilizzata con i thread di lavoro. Per ulteriori informazioni sul ciclo di vita dell'ambiente di esecuzione, consulta [Comprendere il ciclo di vita dell’ambiente di esecuzione Lambda](lambda-runtime-environment.md).
## Versioni di dipendenza
Lambda Managed Instances richiede le seguenti versioni minime del pacchetto:
+ AWS SDK per JavaScript v3: versione 3.933.0 o successiva
+ AWS X-Ray SDK per Node.js: versione 3.12.0 o successiva
+ AWS Distro for OpenTelemetry - Strumentazione per: versione 0.8.0 o successiva JavaScript
+ Powertools for AWS Lambda TypeScript (): versione 2.29.0 o successiva
## Elettroutensili per AWS TypeScript Lambda ()
Powertools for AWS Lambda TypeScript () è compatibile con Lambda Managed Instances e fornisce utilità per la registrazione, il tracciamento, le metriche e altro ancora. Per ulteriori informazioni, vedete [Powertools for AWS Lambda TypeScript](https://github.com/aws-powertools/powertools-lambda-typescript) ().
## Fasi successive
+ Esamina il [runtime Java per le istanze gestite Lambda](lambda-managed-instances-java-runtime.md)
+ [Esamina il runtime Python per le istanze gestite Lambda](lambda-managed-instances-python-runtime.md)
+ Esamina il [runtime di.NET per le istanze gestite da Lambda](lambda-managed-instances-dotnet-runtime.md)
+ Scopri come [scalare le istanze gestite Lambda](lambda-managed-instances-scaling.md)