Suggerimenti utili
Questo documento descrive le best practice per la progettazione, l'implementazione, i test e il deployment di Cloud Functions.
Correttezza
Questa sezione descrive le best practice generali per la progettazione e l'implementazione di Cloud Functions.
Scrivere funzioni idempotenti
Le funzioni dovrebbero produrre lo stesso risultato anche se vengono chiamate più volte. In questo modo, puoi riprovare una chiamata se quella precedente non riesce in parte nel tuo codice. Per maggiori informazioni, consulta la sezione su come ritentare le funzioni basate su eventi.
Assicurati che le funzioni HTTP inviino una risposta HTTP
Se la funzione è attivata da HTTP, ricordati di inviare una risposta HTTP, come mostrato di seguito. Se non lo fai, la funzione potrebbe essere eseguita fino al timeout. In questo caso, ti verrà addebitato l'intero tempo di timeout. I timeout possono anche causare comportamenti imprevedibili o avvii a freddo per le chiamate successive, causando comportamenti imprevedibili o latenza aggiuntiva.
Node.js
Python
Go
Java
C#
Ruby
PHP
Non avviare attività in background
Per attività in background si intende tutto ciò che accade dopo l'interruzione della funzione.
La chiamata di una funzione termina una volta che la funzione restituisce o segnala in altro modo il completamento, ad esempio chiamando l'argomento callback
nelle funzioni basate su eventi Node.js. Qualsiasi codice eseguito dopo la terminazione controllata non può accedere alla CPU e
non procede con l'avanzamento.
Inoltre, quando nello stesso ambiente viene eseguita una chiamata successiva, l'attività in background riprende, interferendo con la nuova chiamata. Ciò può portare a comportamenti imprevisti ed errori difficili da diagnosticare. L'accesso
alla rete dopo la terminazione di una funzione porta in genere alla reimpostazione
delle connessioni (codice di errore ECONNRESET
).
Spesso l'attività in background può essere rilevata nei log dalle singole chiamate, trovando tutto ciò che viene registrato dopo la riga che indica che la chiamata è terminata. L'attività in background a volte può essere nascosta più a fondo nel codice, soprattutto quando sono presenti operazioni asincrone come callback o timer. Rivedi il codice per assicurarti che tutte le operazioni asincrone vengano completate prima di terminare la funzione.
Elimina sempre i file temporanei
Lo spazio di archiviazione del disco locale nella directory temporanea è un file system in memoria. I file che scrivi consumano memoria disponibile per la funzione e talvolta rimangono tra le chiamate. Se non elimini in modo esplicito questi file, potrebbe verificarsi un errore di memoria insufficiente e un successivo avvio a freddo.
Puoi visualizzare la memoria utilizzata da una singola funzione selezionandola nell'elenco di funzioni nella console Google Cloud e scegliendo il grafico Memoria utilizzata.
Non tentare di scrivere al di fuori della directory temporanea e assicurati di utilizzare metodi indipendenti dalla piattaforma/dal sistema operativo per creare percorsi dei file.
Puoi ridurre i requisiti di memoria quando elabori file di dimensioni maggiori utilizzando la pipeline. Ad esempio, puoi elaborare un file su Cloud Storage creando un flusso di lettura, facendolo passare attraverso un processo basato su flusso e scrivendo il flusso di output direttamente in Cloud Storage.
Framework di Functions
Quando esegui il deployment di una funzione, il framework di Functions viene aggiunto automaticamente come dipendenza, utilizzando la versione attuale. Per assicurarti che le stesse dipendenze siano installate in modo coerente in diversi ambienti, ti consigliamo di bloccare la funzione a una versione specifica del framework di Functions.
Per farlo, includi la tua versione preferita nel file di blocco pertinente (ad esempio, package-lock.json
per Node.js o requirements.txt
per Python).
Strumenti
Questa sezione fornisce linee guida su come utilizzare gli strumenti per implementare, testare e interagire con Cloud Functions.
Sviluppo locale
Il deployment delle funzioni richiede un po' di tempo, quindi spesso è più rapido testare il codice della funzione localmente.
Error Reporting
Nei linguaggi che utilizzano la gestione delle eccezioni, non generare eccezioni non rilevate, perché forzano gli avvii a freddo nelle chiamate future. Per informazioni su come segnalare correttamente gli errori, consulta la guida Error Reporting.
Non uscire manualmente
L'uscita manuale può causare comportamenti imprevisti. Usa invece le seguenti espressioni idiomatiche specifiche della lingua:
Node.js
Non usare process.exit()
. Le funzioni HTTP devono inviare una risposta con
res.status(200).send(message)
e le funzioni basate su eventi
usciranno una volta restituite (implicitamente o esplicitamente).
Python
Non usare sys.exit()
. Le funzioni HTTP dovrebbero restituire esplicitamente una risposta sotto forma di stringa, mentre le funzioni basate su eventi escono dall'uscita una volta restituito un valore (implicitamente o esplicitamente).
Go
Non usare os.Exit()
. Le funzioni HTTP dovrebbero restituire esplicitamente una risposta sotto forma di stringa, mentre le funzioni basate su eventi escono dall'uscita una volta restituito un valore (implicitamente o esplicitamente).
Java
Non usare System.exit()
. Le funzioni HTTP devono inviare una risposta con
response.getWriter().write(message)
e le funzioni basate su eventi
usciranno una volta restituite (implicitamente o esplicitamente).
C#
Non usare System.Environment.Exit()
. Le funzioni HTTP devono inviare una risposta con
context.Response.WriteAsync(message)
e le funzioni basate su eventi
usciranno una volta restituite (implicitamente o esplicitamente).
Ruby
Non utilizzare exit()
o abort()
. Le funzioni HTTP dovrebbero restituire esplicitamente una risposta sotto forma di stringa, mentre le funzioni basate su eventi escono dall'uscita una volta restituito un valore (implicitamente o esplicitamente).
PHP
Non utilizzare exit()
o die()
. Le funzioni HTTP dovrebbero restituire esplicitamente una risposta sotto forma di stringa, mentre le funzioni basate su eventi escono dall'uscita una volta restituito un valore (implicitamente o esplicitamente).
Utilizza Sendgrid per inviare email
Cloud Functions non consente connessioni in uscita sulla porta 25, quindi non è possibile stabilire connessioni non sicure a un server SMTP. Il modo consigliato per inviare email è utilizzare SendGrid. Puoi trovare altre opzioni per l'invio di email nel tutorial Invio di email da un'istanza per Compute Engine.
Prestazioni
Questa sezione descrive le best practice per l'ottimizzazione del rendimento.
Usa le dipendenze con oculatezza
Poiché le funzioni sono stateless, l'ambiente di esecuzione viene spesso inizializzato da zero (durante il cosiddetto avvio a freddo). Quando si verifica un avvio a freddo, viene valutato il contesto globale della funzione.
Se le funzioni importano moduli, il tempo di caricamento per questi moduli può aumentare la latenza delle chiamate durante un avvio a freddo. Puoi ridurre questa latenza, nonché il tempo necessario per il deployment della funzione, caricando correttamente le dipendenze e non caricando dipendenze che la funzione non utilizza.
Utilizza le variabili globali per riutilizzare gli oggetti nelle chiamate future
Non vi è alcuna garanzia che lo stato di una Cloud Function verrà conservato per le chiamate future. Tuttavia, Cloud Functions spesso ricicla l'ambiente di esecuzione di una chiamata precedente. Se dichiari una variabile in ambito globale, il suo valore può essere riutilizzato nelle chiamate successive senza dover essere ricalcolato.
In questo modo puoi memorizzare nella cache oggetti che possono essere costosi da ricreare a ogni chiamata di funzione. Lo spostamento di questi oggetti dal corpo della funzione all'ambito globale può portare a miglioramenti significativi delle prestazioni. L'esempio seguente crea un oggetto pesante solo una volta per istanza di funzione e lo condivide in tutte le chiamate di funzione che raggiungono l'istanza specificata:
Node.js
Python
Go
Java
C#
Ruby
PHP
È particolarmente importante memorizzare nella cache le connessioni di rete, i riferimenti alle librerie e gli oggetti client API in ambito globale. Per alcuni esempi, consulta Ottimizzare il networking.
Inizializzazione lazy delle variabili globali
Se inizializza le variabili in ambito globale, il codice di inizializzazione verrà sempre eseguito tramite una chiamata di avvio a freddo, aumentando la latenza della funzione.
In alcuni casi, ciò causa timeout intermittenti per la chiamata dei servizi
se non vengono gestiti correttamente in un blocco try
/catch
. Se alcuni oggetti non vengono utilizzati in tutti i percorsi di codice, valuta la possibilità di inizializzarli in modo lento on demand:
Node.js
Python
Go
Java
C#
Ruby
PHP
Le funzioni PHP non possono conservare variabili tra le richieste. L'esempio degli ambiti riportato sopra utilizza il caricamento lento per memorizzare nella cache i valori delle variabili globali in un file.
Ciò è particolarmente importante se definisci varie funzioni in un singolo file e funzioni diverse usano variabili diverse. A meno che non utilizzi l'inizializzazione lazy, potresti sprecare risorse su variabili che sono state inizializzate ma mai utilizzate.
Riduci gli avvii a freddo impostando un numero minimo di istanze
Per impostazione predefinita, Cloud Functions scala il numero di istanze in base al numero di richieste in entrata. Puoi modificare questo comportamento predefinito impostando un numero minimo di istanze che Cloud Functions deve tenere pronte per gestire le richieste. L'impostazione di un numero minimo di istanze riduce gli avvii a freddo dell'applicazione. Ti consigliamo di impostare un numero minimo di istanze se la tua applicazione è sensibile alla latenza.
Per informazioni su come impostare un numero minimo di istanze, consulta Utilizzare il numero minimo di istanze.
Risorse aggiuntive
Scopri di più sull'ottimizzazione delle prestazioni nel video "Google Cloud Performance Atlas" Tempo di avvio a freddo di Cloud Functions.