Domande frequenti su AWS Lambda

Per un elenco completo delle origini degli eventi, consulta la documentazione.

AWS Lambda offre supporto nativo a codici Java, Go, PowerShell, Node.js, C#, Python e Ruby e fornisce un'API Runtime che permette di utilizzare qualsiasi altro linguaggio di programmazione per creare le tue funzioni. Consulta la documentazione relativa all'utilizzo di Node.js, Python, Java, Ruby, C#, Go ePowerShell.

Ogni funzione di AWS Lambda viene eseguita nel rispettivo ambiente isolato, con una visualizzazione del file system e risorse proprie. AWS Lambda utilizza le stesse tecniche di Amazon EC2 per offrire sicurezza e separazione a livello di infrastruttura e di esecuzione. Per ulteriori informazioni, consulta la documentazione.

AWS Lambda archivia il codice in Amazon S3 e lo crittografa su disco. AWS Lambda esegue controlli dell'integrità aggiuntivi mentre il codice è in uso. Per informazioni sensibili quali le password di database, consigliamo di utilizzare la crittografia lato client tramite il Servizio AWS di gestione delle chiavi (AWS KMS) e di archiviare i valori risultanti come testo criptato nella variabile di ambiente. Sarà necessario includere nel codice della funzione di AWS Lambda la logica per decrittografare tali valori. Per ulteriori informazioni,consulta la documentazione.

Sì. Puoi creare e modificare variabili di ambiente tramite la console, l'interfaccia a riga di comando o i kit SDK di AWS Lambda. Per ulteriori informazioni sulle variabili di ambiente, consulta la documentazione.

Per informazioni sensibili quali le password di database, consigliamo di utilizzare la crittografia lato client tramite il Servizio AWS di gestione delle chiavi (AWS KMS) e di archiviare i valori risultanti come testo criptato nella variabile di ambiente. Sarà necessario includere nel codice della funzione di AWS Lambda la logica per decrittografare tali valori.

Sì. Inoltre, puoi suddividere il codice in pacchetti (framework, SDK, librerie e molto altro) come un livello Lamba e gestirli e condividerli facilmente tra diverse funzioni.

Le funzioni Lambda sono monitorate automaticamente da AWS Lambda, comunicando i parametri in tempo reale tramite Amazon CloudWatch, ad esempio richieste totali, utilizzo simultaneo a livello di account e di funzione, latenza, percentuale di errori e richieste respinte a causa delle limitazioni. È anche possibile visualizzare le statistiche per ogni singola funzione Lambda tramite la console di Amazon CloudWatch o la console di AWS Lambda. Inoltre, è possibile richiamare API di monitoraggio di terze parti in una funzione Lambda.
 

Per ulteriori informazioni, visita la pagina sulla risoluzione dei problemi dei parametri di CloudWatch. Per l'utilizzo di parametri integrati di Lambda vengono applicate le tariffe standard di AWS Lambda.

Nel modello di risorsa di AWS Lambda puoi scegliere la quantità di memoria desiderata per la tua funzione perché potenza della CPU e altre risorse vengano allocate in modo proporzionale. Se ad esempio scegli 256 MB di memoria, alla tua funzione Lambda verrà allocato circa il doppio di potenza della CPU rispetto a quanto otterresti richiedendo 128 MB di memoria e circa la metà di potenza della CPU rispetto a una richiesta di 512 MB di memoria. Per ulteriori informazioni, consulta la documentazione sulla configurazione delle funzioni.

Puoi impostare la memoria da 128 MB a 10.240 MB.

Le tariffe di AWS Lambda vengono addebitate in base all'utilizzo. Per ulteriori informazioni, visita la pagina Prezzi di AWS Lambda.

Sì. Per impostazione predefinita, a ogni funzione di AWS Lambda è associata un'unica versione corrente del codice. I client della funzione Lambda possono richiamare una versione specifica o ottenere l'implementazione più recente. Consulta la documentazione sul versionamento delle funzioni Lambda.

AWS Lambda offre opzioni di distribuzione flessibili: funzioni di pacchetto e di distribuzione, come archivi di file .zip, da caricare direttamente tramite console, interfaccia della riga di comando (CLI, Command Line Interface) o SDK, oppure come immagini di container. Entrambi i metodi prevedono lo stesso ambiente di esecuzione, la stessa scalabilità la stessa semplicità operativa, permettendo di adottare l'approccio più adatto al flusso di lavoro.

Puoi invocare una funzione Lambda utilizzando un evento personalizzato tramite l'API di invocazione di AWS Lambda. La funzione può essere richiamata solo dal suo proprietario o da un altro account AWS a cui il proprietario abbia concesso il permesso. Per ulteriori informazioni, consulta la Guida per gli sviluppatori Lambda.

AWS Lambda SnapStart può migliorare le prestazioni di avvio da alcuni secondi a meno di un secondo per le applicazioni sensibili alla latenza. Il funzionamento di SnapStart si basa sulla creazione di uno snapshot dello stato della memoria (e del disco) inizializzata della funzione e sulla memorizzazione di tale snapshot nella cache per un accesso a bassa latenza. In seguito, quando la funzione viene invocata, Lambda riprende gli ambienti di esecuzione da questo snapshot preinizializzato invece di inizializzarli da zero, migliorando la latenza di avvio. Per la resilienza, Lambda mantiene le copie memorizzate nella cache dello snapshot e applica automaticamente gli aggiornamenti software, come aggiornamenti di runtime e patch di sicurezza. Per ulteriori informazioni, consulta la documentazione.

Lambda SnapStart è una semplice configurazione a livello di funzione che può essere configurata per funzioni nuove ed esistenti utilizzando l'API Lambda, la Console di gestione AWS, l'interfaccia a riga di comando AWS (AWS CLI), il kit AWS SDK, il Cloud Development Kit AWS (AWS CDK), AWS CloudFormation e il Modello di applicazione serverless AWS (AWS SAM). Quando configuri Lambda SnapStart, ogni versione della funzione pubblicata successivamente beneficia delle migliori prestazioni di avvio offerte da Lambda SnapStart. Per ulteriori informazioni su Lambda SnapStart, consulta la documentazione.

Lambda SnapStart è un'ottimizzazione delle prestazioni che consente alle funzioni di ottenere tempi di avvio più rapidi riducendo la latenza variabile sostenuta durante l'esecuzione di un codice di inizializzazione una tantum. Sebbene Lambda SnapStart riduca la latenza di avvio, funziona come ottimizzazione best-effort e non garantisce l'eliminazione degli avvii a freddo. Se la tua applicazione ha requisiti di latenza rigorosi e richiede tempi di avvio in millisecondi a due cifre, ti consigliamo di utilizzare PC.

Lambda SnapStart supporta più runtime, tra cui Java 11 (e versioni successive), Python 3.12 (e versioni successive) e .NET 8 (e versioni successive). Le versioni future dei runtime saranno supportate dopo il loro rilascio. Per tutti i runtime supportati da Lambda, consulta la documentazione dei runtime Lambda.

Sì. Una funzione Lambda SnapStart può essere configurata per accedere alle risorse in un cloud privato virtuale (VPC). Per ulteriori informazioni su come configurare la funzione con un VPC, consulta la documentazione di Lambda.

Sì, ti verrà addebitato il costo della memorizzazione nella cache di uno snapshot nel periodo in cui la versione della funzione è attiva, per un minimo di 3 ore e successivamente per millisecondo. Il prezzo dipende dalla quantità di memoria allocata per la funzione. Inoltre, viene addebitato un costo ogni volta che Lambda riprende un ambiente di esecuzione ripristinando lo snapshot. In questo caso, il prezzo dipende dalla quantità di memoria allocata per la funzione. Per ulteriori informazioni sui prezzi di SnapStart, consulta la pagina Prezzi di AWS Lambda.

I prezzi di SnapStart non si applicano ai runtime gestiti da Java supportati, che possono memorizzare nella cache uno snapshot solo per un massimo di 14 giorni.

La simultaneità con provisioning ti offre maggiore controllo sulle prestazioni delle applicazioni serverless. Quando è abilitata, la simultaneità con provisioning mantiene le funzioni già inizializzate e pronte a reagire in meno di 100 millisecondi.

Puoi configurare la simultaneità sulla funzione attraverso la Console di gestione AWS, l'API Lambda, AWS CLI e AWS CloudFormation. Il modo più semplice per sfruttare Provisioned Concurrency è tramite l'utilizzo di AWS Auto Scaling. Puoi utilizzare Application Auto Scaling per configurare le pianificazioni o lascia che Auto Scaling regoli automaticamente il livello di Provisioned Concurrency in tempo reale in base alle necessità. Per ulteriori informazioni sulla simultaneità con provisioning, consulta la documentazione.

La simultaneità con provisioning aggiunge una dimensione di prezzi, "Simultaneità con provisioning", per mantenere le funzioni già inizializzate. Quando abilitato, l'importo verrà calcolato in base alla quantità di simultaneità e alla durata configurate. Quando è in esecuzione una funzione su cui è configurato Provisioned Concurrency, i prezzi sono calcolati anche sulle richieste e sulla durata dell'esecuzione. Per ulteriori informazioni sui prezzi della simultaneità con provisioning, consulta la pagina Prezzi di AWS Lambda.

Lambda@Edge permette di eseguire il codice in tutte le sedi AWS a livello globale senza effettuare il provisioning o gestire i server, inviando risposte agli utenti finali alla latenza di rete più bassa possibile. È sufficiente caricare il codice Node.js o Python in AWS Lambda e configurare la funzione in modo che venga attivata in risposta alle richieste di Amazon CloudFront (ad esempio quando arriva una richiesta di visualizzazione, quando viene inoltrata o ricevuta una richiesta dall'origine e subito prima della risposta all'utente finale). Il codice è quindi pronto per essere eseguito in qualsiasi edge location AWS da cui è stata ricevuta la richiesta, ridimensionando le risorse in base al volume di richieste di CloudFront globali. Per ulteriori informazioni, consulta la nostra documentazione.

Per utilizzare Lambda@Edge è sufficiente caricare il codice su AWS Lambda e associare una versione della funzione da attivare in risposta alle richieste di Amazon CloudFront. Il codice deve soddisfare le limitazioni di servizio di Lambda@Edge. Al momento Lambda@Edge supporta codice Node.js e Python per le chiamate globali da parte di eventi CloudFront. Per ulteriori informazioni, consulta la nostra documentazione.

Lambda@Edge è ottimizzato per i casi d'uso sensibili alla latenza in cui i visualizzatori finali sono distribuiti a livello globale. Idealmente, tutte le informazioni necessarie per prendere una decisione sono disponibili presso una edge location CloudFront, tra funzione e richiesta. Pertanto, nei casi d'uso in cui è necessario prendere decisioni su come distribuire i contenuti in base alle caratteristiche degli utenti (ad esempio, posizione, dispositivo client e così via), l'elaborazione può essere eseguita in prossimità degli utenti, senza dover reindirizzare i dati a un server centralizzato.

Le funzioni Lambda esistenti possono essere associate a eventi CloudFront per invocazioni globali, se la funzione soddisfa requisiti e limitazioni di Lambda@Edge. Puoi trovare ulteriori informazioni su come aggiornare le proprietà delle funzioni qui.

No. AWS Lambda è progettato per l'esecuzione in parallelo di molte istanze delle funzioni. Tuttavia, AWS Lambda impone un limite di sicurezza predefinito di esecuzioni simultanee per account per ogni regione. Puoi trovare ulteriori informazioni sui limiti di sicurezza predefiniti qui. È anche possibile controllare il numero massimo di esecuzioni simultanee per singole funzioni di AWS Lambda per riservare una parte del limite di simultaneità degli account a funzioni chiave oppure limitare il tasso di traffico verso le risorse a valle.

Se desideri inviare una richiesta per aumentare il limite di esecuzioni simultanee, puoi utilizzare Service Quotas per presentare una richiesta di aumento del limite.

Una volta superato il limite massimo di esecuzioni simultanee, le funzioni di AWS Lambda invocate in modo sincrono restituiscono un errore di limitazione (codice di errore 429). Le funzioni Lambda richiamate in modo asincrono possono assorbire notevoli picchi di traffico per circa 15-30 minuti, dopo i quali gli eventi in entrata vengono rifiutati come limitati. Se la funzione Lambda viene richiamata in risposta a eventi di Amazon S3, gli eventi rifiutati da AWS Lambda possono essere mantenuti e ritentati da S3 per 24 ore. Gli eventi provenienti da flussi Amazon Kinesis e flussi Amazon DynamoDB vengono ritentati fino a quando la funzione Lambda non riesce o fino allo scadere dei dati. I flussi Amazon Kinesis e Amazon DynamoDB mantengono i dati per 24 ore.

Il limite massimo predefinito di esecuzioni simultanee si applica a livello di account. Tuttavia, è inoltre possibile impostare limiti anche su singole funzioni (vai qui per informazioni sulla simultaneità riservata).

Ogni funzione Lambda invocata in modo sincrono può dimensionare a una velocità fino a 1.000 esecuzioni simultanee ogni 10 secondi. Sebbene la velocità di dimensionamento di Lambda sia adeguata alla maggior parte dei casi d'uso, risulta particolarmente adatta a quelli con picchi di traffico prevedibili o imprevedibili. Ad esempio, l'elaborazione dei dati associati all'accordo sul livello di servizio (SLA) richiede un dimensionamento prevedibile ma rapido per soddisfare la domanda di elaborazione. Allo stesso modo, la pubblicazione di articoli su ultime notizie o su vendite lampo può generare livelli di traffico imprevedibili in un breve periodo di tempo. La velocità di dimensionamento di Lambda può facilitare i casi d'uso in questione senza configurazioni o strumenti aggiuntivi. Inoltre, il limite di dimensionamento della simultaneità è un limite a livello di funzione, il che significa che ogni funzione dell'account si dimensiona indipendentemente dalle altre.

Se si supera la policy di ripetizione tentativi per le invocazioni asincrone, è possibile configurare una coda DLQ all'interno della quale verrà inserito l'evento. In assenza di una coda DLQ configurata, l'evento potrebbe essere rifiutato. Se si supera la policy di ripetizione tentativi per le invocazioni basate su flussi, i dati sarebbero già scaduti e pertanto rifiutati.

Puoi concedere alla funzione Lambda le autorizzazioni necessarie per accedere ad altre risorse utilizzando un ruolo IAM. AWS Lambda assume il ruolo durante l'esecuzione della funzione Lambda, assicurandoti sempre il controllo completo e sicuro esattamente su tutte le risorse AWS che possono essere usate dalla funzione. Per ulteriori informazioni sui ruoli, visita la sezione Configurazione di AWS Lambda.

Quando configuri un bucket Amazon S3 per l'invio di messaggi a una funzione di AWS Lambda, viene creata una regola di policy per le risorse per la concessione dell'accesso. Per ulteriori informazioni sulle policy delle risorse e dei controlli degli accessi per le funzioni Lambda, consulta la Guida per gli sviluppatori di Lambda.

I controlli degli accessi vengono gestiti tramite il ruolo della funzione Lambda. Il ruolo assegnato alla funzione Lambda determina anche le risorse di cui AWS Lambda può eseguire il polling per conto della funzione. Per ulteriori informazioni, consulta la Guida per gli sviluppatori AWS Lambda.

Puoi abilitare le funzioni Lambda per accedere alle risorse nel VPC specificando la sottorete e il gruppo di sicurezza come parte della configurazione della funzione. Le funzioni Lambda configurate per accedere alle risorse in un cloud privato virtuale specifico non hanno di default accesso a Internet. Per concedere Internet a queste funzioni, utilizza i gateway Internet. Per impostazione predefinita, le funzioni Lambda comunicano con le risorse in un VPC dual stack su IPv4. Puoi configurare le tue funzioni per accedere alle risorse in un VPC dual stack su IPv6. Per ulteriori informazioni sulle funzioni Lambda configurate con VPC, consulta la sezione Rete privata Lambda con VPC.

La firma del codice per AWS Lambda offre controlli di affidabilità e integrità che permettono di verificare che nelle funzioni Lambda venga distribuito solo codice inalterato proveniente da sviluppatori approvati. Puoi utilizzare AWS Signer, un servizio di firma del codice completamente gestito, per firmare digitalmente gli artefatti di codice e configurare le funzioni Lambda al fine di verificare le firme durante l'implementazione. La firma del codice per AWS Lambda è attualmente disponibile solo per le funzioni salvate come archivi ZIP.

Puoi creare artefatti di codice con firma digitale utilizzando un profilo di firma tramite la console AWS Signer, l'API del firmatario, AWS SAM CLI o AWS CLI. Per ulteriori informazioni, consulta la documentazione per AWS Signer.

Durante la distribuzione, AWS Lambda può eseguire i seguenti controlli della firma:

• Firma corrotta: si verifica se l'elemento di codice è stato modificato dopo la firma.
• Firma non corrispondente: si verifica se l'elemento di codice è firmato da un profilo di firma non approvato.
• Firma scaduta: si verifica se la firma ha superato la data di scadenza configurata.
• Firma revocata: si verifica se il proprietario del profilo di firma revoca le attività di firma.

Per ulteriori informazioni, consulta la documentazione su AWS Lambda.

Non sono previsti costi aggiuntivi per l'utilizzo della firma del codice per AWS Lambda. Paghi il prezzo standard per AWS Lambda. Per ulteriori informazioni, consulta la pagina relativa ai prezzi.

Per offrirti un'esperienza di registrazione semplificata e migliorata per impostazione predefinita, AWS Lambda offre controlli di registrazione avanzati, come la capacità di acquisire nativamente i log delle funzioni Lambda in formato strutturato JSON, controllare il filtraggio a livello di log dei log delle funzioni Lambda senza apportare modifiche al codice e personalizzare il gruppo di log di Amazon CloudWatch a cui Lambda invia i log.

Puoi acquisire i log delle funzioni Lambda in formato strutturato JSON senza dover utilizzare le librerie di registrazione. I log strutturati JSON semplificano la ricerca, il filtraggio e l'analisi di grandi volumi di voci di log. È possibile controllare il filtraggio a livello di log dei log delle funzioni Lambda senza apportare modifiche al codice, il che consente di scegliere il livello di granularità di registrazione richiesto per le funzioni Lambda senza setacciare grandi volumi di log durante il debug e la risoluzione degli errori. Inoltre, puoi impostare a quale gruppo di log di Amazon CloudWatch Lambda invia i log, semplificando l'aggregazione dei log di più funzioni all'interno di un'applicazione in un'unica posizione. È quindi possibile applicare le policy di sicurezza, governance e conservazione ai log a livello di applicazione anziché singolarmente a ciascuna funzione.

Puoi specificare controlli di registrazione avanzati per le funzioni Lambda utilizzando l'API AWS Lambda, la console di AWS Lambda, AWS CLI, il Modello di applicazione serverless AWS (AWS SAM) e AWS CloudFormation. Per saperne di più, leggi il post sul blog di lancio per i controlli di registrazione avanzati o la Guida per gli sviluppatori di Lambda.

Sì, puoi utilizzare le tue librerie di registrazione per generare log Lambda in formato strutturato JSON. Per garantire che le tue librerie di registrazione funzionino perfettamente con la funzionalità di registrazione strutturata JSON nativa di Lambda, Lambda non codificherà due volte i log generati dalla tua funzione che sono già codificati in JSON. Puoi anche utilizzare la libreria Powertools per AWS Lambda per acquisire i log Lambda in formato strutturato JSON.

Non sono previsti costi aggiuntivi per l'utilizzo dei controlli di registrazione avanzati su Lambda. L'importazione e l'archiviazione dei log Lambda continueranno a essere addebitati da File di log Amazon CloudWatch. Per informazioni sui prezzi dei log, visita la pagina Prezzi di CloudWatch.

CloudWatch Application Signals è una soluzione di monitoraggio delle prestazioni delle applicazioni (APM, Application Performance Monitoring) che permette a sviluppatori e operatori di monitorare facilmente l’integrità e le prestazioni delle applicazioni serverless create con Lambda. Application Signals fornisce dashboard predefinite e standardizzate per i parametri chiave delle applicazioni, le tracce correlate e le interazioni tra le funzioni Lambda e le relative dipendenze, il tutto senza richiedere strumentazione manuale o modifiche al codice da parte degli sviluppatori.

CloudWatch Logs Live Tail è una funzionalità interattiva di analisi e flusso di log che fornisce visibilità in tempo reale nei log, semplificando lo sviluppo e la risoluzione dei problemi delle funzioni Lambda. Ciò permette agli sviluppatori di testare e convalidare rapidamente le modifiche al codice o alla configurazione in tempo reale, accelerando il ciclo author-test-deploy (noto anche come "ciclo di sviluppo interno") durante la creazione di applicazioni con Lambda. Inoltre, l'esperienza Live Tail permette agli operatori e ai team DevOps di rilevare ed eseguire il debug di guasti ed errori critici nel codice della funzione Lambda, riducendo il tempo medio di ripristino durante la risoluzione degli errori della funzione Lambda.

Utilizza le funzioni Lambda a lunga durata quando vuoi implementare una logica all'interno del modello di programmazione familiare di Lambda, con supporto per test in locale, integrazione IDE e utilizzo del linguaggio di programmazione preferito. Utilizza AWS Step Functions per progettare visivamente i flussi di lavoro, garantire la visibilità tra team, sfruttare più di 220 integrazioni di servizio native o gestire automaticamente l'infrastruttura. Molte applicazioni traggono vantaggio dall'utilizzo combinato di entrambe le soluzioni.

Le funzioni a lunga durata di AWS Lambda attualmente supportano JavaScript, TypeScript, Python e Java. Scopri di più sui runtime supportati.

Per informazioni aggiornate sulla disponibilità nelle regioni, consulta la pagina Funzionalità dei servizi AWS per regione.

Sì. Nonostante il timeout per singola invocazione rimanga di 15 minuti, le funzioni Lambda a lunga durata possono sospendersi e riprendere su più invocazioni utilizzando funzionalità di attesa, come timer, callback e condizioni di polling. Quando le funzioni a lunga durata vengono invocate in modo asincrono, il timeout di esecuzione durevole può arrivare fino a 1 anno, consentendo casi d'uso come flussi di lavoro con approvazione manuale, promemoria pianificati e pipeline di elaborazione che si estendono su più giorni. Per le funzioni su richiesta, non sono previsti costi di elaborazione durante la sospensione.

Il timeout di esecuzione (fino a 1 anno) determina la durata di un'esecuzione. Il periodo di conservazione (fino a 90 giorni) determina per quanto tempo i dati della cronologia e dei checkpoint vengono conservati una volta completata l'esecuzione. La conservazione non influisce sulle esecuzioni in corso. Consulta la sezione Configurazione delle funzioni a lunga durata.

No. Per le funzioni su richiesta, quando si utilizzano le funzionalità di attesa dell'SDK di esecuzione a lunga durata, non sono previsti costi di elaborazione durante la sospensione dell'attività. Per ulteriori informazioni, consulta la  pagina dei prezzi e la Guida per gli sviluppatori.

Ogni unità di lavoro può essere organizzata in una fase con tentativi automatici. Se non è possibile eseguire una fase dopo un nuovo tentativo, il codice del gestore può rilevare l'errore e avviare operazioni di compensazione, come rimborsare un pagamento o rendere una prenotazione di nuovo disponibile. Ogni fase completata viene salvata come checkpoint, incluse le operazioni di compensazione. Non vengono effettuati nuovi tentativi su attività completate. Questo modello permette di creare processi affidabili in più fasi, come l'evasione degli ordini o i flussi di lavoro di pagamento, senza dover implementare logiche personalizzate per la gestione dei tentativi e il monitoraggio dello stato.

Lo stato di esecuzione è memorizzato in un archivio interno completamente gestito. Ogni operazione con checkpoint, ad esempio una fase o una chiamata, può memorizzare fino a 256 KB di dati. Questo limite si applica ai dati restituiti da un'operazione. I dati elaborati durante un'operazione, come la lettura e la scrittura di oggetti S3 di grandi dimensioni, non rientrano in questo limite. Qualora sia necessario ottenere risultati di grandi dimensioni, è possibile configurare serializzatori personalizzati nell'SDK per gestire payload elevati in Amazon S3 o Amazon DynamoDB, mantenendo il checkpoint solo come riferimento.

Le funzioni Lambda a lunga durata utilizzano lo stesso pool di simultaneità a livello di account delle funzioni Lambda standard. Gli slot simultanei vengono resi disponibili durante le fasi di attesa, permettendo a migliaia di esecuzioni di restare in sospeso senza occupare risorse di concorrenza. Scopri di più sulle quote AWS Lambda.

Le funzioni a lunga durata possono essere testate in locale senza credenziali AWS utilizzando l'SDK di esecuzione durevole per il linguaggio di programmazione supportato. AWS SAM CLI supporta anche invocazioni locali, callback e gestione a lunga durata dell'esecuzione, facilitando lo sviluppo e il debug prima della distribuzione. Scopri di più sui test delle funzioni a lunga durata.