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à.
# Ciclo di vita dell'ambiente di esecuzione
Un ambiente di esecuzione è un'istanza di calcolo isolata che esegue il server HTTP. AWS Lambda crea ambienti di esecuzione per la tua funzione Web Lambda all'arrivo del traffico. Indirizza le richieste verso ambienti attivi e rimuove gli ambienti che non sono più necessari. La comprensione di questo ciclo di vita consente di ottimizzare le prestazioni di avvio e scrivere codice che gestisca correttamente l'inizializzazione e l'arresto.
## Fasi del ciclo di vita
Ogni ambiente di esecuzione passa attraverso le seguenti fasi:
| Fase | Cosa succede | Gestione delle richieste |
| --- | --- | --- |
| Inizializzazione | Lambda carica il codice, prepara il runtime e avvia il processo del server HTTP. Il server deve iniziare ad ascoltare l'indirizzo AWS\_LAMBDA\_HTTP\_ENDPOINT entro 10 secondi. | L'ambiente non può soddisfare le richieste durante l'inizializzazione. |
| Pronto | Il server HTTP è in ascolto e l'ambiente è disponibile per ricevere le richieste. Lambda indirizza le richieste in arrivo verso questo ambiente. | L'ambiente accetta richieste fino al maxConcurrencyPerEnvironment limite. |
| Arresto | Lambda interrompe l'instradamento di nuove richieste verso l'ambiente, lascia che le richieste in corso vengano completate nel miglior modo possibileSIGTERM, invia e quindi chiude l'ambiente. | Nessuna nuova richiesta viene indirizzata all'ambiente. In-flight le richieste possono continuare, ma il completamento non è garantito. DopoSIGTERM, il processo ha fino a 1 secondo per completare la pulizia. Lo stato del processo viene perso. |
## Inizializzazione (avvio a freddo)
Quando Lambda crea un nuovo ambiente di esecuzione, la fase di inizializzazione include i seguenti passaggi:
1. Lambda carica il codice dal tuo pacchetto di distribuzione.zip.
1. Lambda configura l'ambiente di runtime (incluse Node.js le variabili di ambiente).
1. Lambda avvia il processo di candidatura.
1. Il server HTTP inizia ad ascoltare sull'host e sulla porta specificati dalla variabile di `AWS_LAMBDA_HTTP_ENDPOINT` ambiente. Deve iniziare l'ascolto entro 10 secondi.
1. Lambda rileva che il server è in ascolto e contrassegna l'ambiente come pronto.
Un avvio a freddo si verifica quando Lambda deve creare un nuovo ambiente per gestire una richiesta perché non ci sono ambienti disponibili. La prima richiesta dopo un avvio a freddo presenta una latenza aggiuntiva rispetto alla fase di inizializzazione. Le richieste successive allo stesso ambiente non comportano questo costo.
Per ridurre l'impatto dell'avviamento a freddo:
+ Riduci al minimo le dimensioni del pacchetto di distribuzione. I pacchetti più piccoli si caricano più velocemente.
+ Riduci i tempi di avvio del server. Rimanda l'inizializzazione complessa (ad esempio il caricamento di file di dati di grandi dimensioni) a dopo l'inizio dell'ascolto del server. Lambda indirizza le richieste all'ambiente non appena il server è in ascolto, quindi fai in modo che i gestori di richieste che dipendono dal lavoro posticipato aspettino che finisca, ad esempio in attesa di una promessa condivisa.
+ Utilizza l'inizializzazione lenta per le connessioni al database e i client di servizi esterni. Stabilisci connessioni alla prima richiesta anziché all'avvio.
## Scale-down e spegnimento
Lambda monitora l'utilizzo dell'ambiente degli endpoint e rimuove gli ambienti non necessari, ad esempio quando il traffico diminuisce. Prima di rimuovere un ambiente, Lambda utilizza la seguente sequenza di spegnimento:
1. Lambda interrompe l'instradamento di nuove richieste verso l'ambiente.
1. Lambda consente di completare al meglio le richieste in volo.
1. Lambda invia. `SIGTERM` Il processo ha fino a 1 secondo per completare la pulizia prima che Lambda la termini e rimuova l'ambiente.
In assenza di traffico, Lambda ridimensiona la funzione Web fino a zero ambienti. La richiesta successiva dopo un periodo di scalabilità a zero attiva un nuovo avvio a freddo.
Se l'applicazione deve eseguire la pulizia durante lo spegnimento, gestisci. `SIGTERM` La pulizia deve terminare entro 1 secondo. Non fate affidamento sull'esecuzione dei callback di spegnimento, perché Lambda non può garantire un arresto corretto in tutte le modalità di errore, ad esempio un guasto hardware sottostante.
L'esempio seguente gestisce: `SIGTERM`
```
process.on('SIGTERM', () => {
// Finish short cleanup, such as flushing buffered logs, within 1 second.
process.exit(0);
});
```
## Riutilizzo dell'ambiente
Lambda riutilizza gli ambienti di esecuzione su più richieste per evitare ripetuti avviamenti a freddo. Un singolo ambiente può soddisfare migliaia di richieste durante il suo ciclo di vita. Ciò significa che:
+ **Lo stato globale persiste**: le variabili, le cache e le connessioni inizializzate dal server all'avvio persistono tra le richieste. È possibile utilizzarlo per la memorizzazione nella cache in memoria o il pool di connessioni.
+ **Lo stato del file system persiste**: i file che il codice scrive nel file system locale (ad esempio`/tmp`) persistono finché Lambda non rimuove l'ambiente.
+ **Nessuna durata garantita**: Lambda può rimuovere un ambiente in qualsiasi momento. Non fare affidamento su un ambiente che duri per una durata specifica. Conserva i dati importanti in un archivio esterno come DynamoDB o Amazon S3.
## Gestione simultanea delle richieste
Ogni ambiente di esecuzione di Web Function gestisce più richieste HTTP simultanee. L'`maxConcurrencyPerEnvironment`impostazione della revisione controlla il numero massimo di richieste simultanee per ambiente.
Poiché il server gestisce più richieste contemporaneamente, il codice deve essere sicuro per l'uso simultaneo:
+ Non memorizzate lo stato di ogni richiesta in variabili globali. Utilizzate invece variabili con ambito di richiesta o contesto middleware.
+ Proteggi gli stati mutabili condivisi, come le cache o i contatori, che modifichi oltre i limiti. `await` Le richieste si intersecano nel ciclo degli eventi. Se una sequenza di lettura-modifica-scrittura comprende un'operazione asincrona, un'altra richiesta in corso può leggere o modificare lo stato prima del termine della sequenza.
+ Tieni presente che utilizza un ciclo di eventi a thread singolo. Node.js CPU-intensive le operazioni sincrone bloccano tutte le richieste simultanee in quell'ambiente. Usa la modalità asincrona I/O ed evita di bloccare il ciclo degli eventi.
Per ulteriori informazioni sulle impostazioni e l'ottimizzazione della concorrenza, vedere. [Comportamento di scalabilità per Lambda Web Functions](web-functions-scaling.md)