Trucchi e suggerimenti
Questo documento descrive le best practice per progettazione, implementazione, test e il deployment delle funzioni Cloud Run.
Correttezza
Questa sezione descrive le best practice generali per la progettazione e l'implementazione le funzioni di Cloud Run.
Scrivere funzioni idempotenti
Le funzioni devono produrre lo stesso risultato anche se vengono chiamate più volte. In questo modo puoi riprovare a eseguire un'invocazione se quella precedente non va a buon fine nel corso del codice. Per ulteriori informazioni, consulta Riprovare le funzioni basate su eventi.
Assicurati che le funzioni HTTP inviino una risposta HTTP
Se la funzione è attivata da HTTP, ricorda di inviare una risposta HTTP, come mostrato di seguito. In caso contrario, la funzione potrebbe essere eseguita fino al timeout. In questo caso, ti verranno addebitati i costi l'intero tempo di timeout. I timeout possono anche causare un comportamento imprevedibile o avviamenti a freddo nelle chiamate successive, con conseguente comportamento imprevedibile o latenza aggiuntiva.
Node.js
Python
Vai
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 quando la funzione restituisce o segnala in altro modo
il completamento, ad esempio chiamando l'argomento callback
in Node.js basato su eventi
funzioni. Qualsiasi codice eseguito dopo l'interruzione controllata non può accedere alla CPU e non farà alcun progresso.
Inoltre, quando nello stesso ambiente viene eseguita una chiamata successiva,
l'attività in background riprende, interferendo con la nuova chiamata. Questo può
generare comportamenti ed errori imprevisti difficili da diagnosticare. L'accesso alla rete al termine di una funzione di solito comporta la reimpostazione delle connessioni (codice di errore ECONNRESET
).
Spesso l'attività in background può essere rilevata nei log delle singole invocazioni, trovandovi tutto ciò che viene registrato dopo la riga che indica il termine dell'invocazione. A volte l'attività in background può essere nascosta più in profondità nel codice, soprattutto quando sono presenti operazioni asincrone come callback o timer. Esamina il codice per assicurarti che tutte le operazioni asincrone vengano completate prima di termina la funzione.
Eliminare sempre i file temporanei
Lo spazio di archiviazione del disco locale nella directory temporanea è un file system in memoria. I file che scrivi consumano la memoria disponibile per la tua funzione e a volte rimangono tra le chiamate. Se non elimini in modo esplicito questi file, potresti genererà un errore di memoria insufficiente e un successivo avvio a freddo.
Puoi visualizzare la memoria utilizzata da una singola funzione selezionandola nell'elenco delle funzioni nella console Google Cloud e scegliendo il grafico Utilizzo della memoria.
Non tentare di scrivere all'esterno della directory temporanea e assicurati di utilizzare metodi indipendenti dalla piattaforma/dal sistema operativo per creare i percorsi dei file.
Puoi ridurre i requisiti di memoria durante l'elaborazione di file di grandi dimensioni utilizzando la pipeline. Ad esempio, puoi elaborare un file su Cloud Storage creando uno stream di lettura, passandolo attraverso un processo basato su stream e scrivendo lo stream di output direttamente su Cloud Storage.
Framework di Functions
Quando esegui il deployment di una funzione, il framework Functions viene aggiunto automaticamente come dipendenza utilizzando la versione corrente. Per assicurarti che le stesse dipendenze vengano installate in modo coerente in ambienti diversi, ti consigliamo di fissare la funzione a una versione specifica del framework 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 le funzioni Cloud Run.
Sviluppo locale
Il deployment delle funzioni richiede un po' di tempo, quindi spesso è più rapido testare il codice della tua funzione in locale.
Error Reporting
Nei linguaggi che utilizzano la gestione delle eccezioni, non lanciare eccezioni non rilevate, perché forzano gli avvii a freddo nelle invocazioni future. Per informazioni su come eseguire una segnalazione, consulta la guida Error Reporting come segnalare correttamente gli errori.
Non uscire manualmente
L'uscita manuale può causare comportamenti imprevisti. Utilizza invece le seguenti espressioni idiomatiche specifiche per lingua:
Node.js
Non utilizzare process.exit()
. Le funzioni HTTP devono inviare una risposta con
res.status(200).send(message)
e basato su eventi
le funzioni usciranno una volta restituite (implicitamente o esplicitamente).
Python
Non usare sys.exit()
. Le funzioni HTTP devono restituire esplicitamente
una risposta sotto forma di stringa, mentre le funzioni basate su eventi usciranno
restituiscono un valore (implicitamente o esplicitamente).
Vai
Non usare os.Exit()
. Le funzioni HTTP devono restituire esplicitamente
una risposta sotto forma di stringa, mentre le funzioni basate su eventi usciranno
restituiscono un valore (implicitamente o esplicitamente).
Java
Non utilizzare System.exit()
. Le funzioni HTTP devono inviare una risposta con response.getWriter().write(message)
e le funzioni basate sugli eventi usciranno al loro ritorno (implicitamente o esplicitamente).
C#
Non utilizzare System.Environment.Exit()
. Le funzioni HTTP devono inviare una risposta con
context.Response.WriteAsync(message)
e basato su eventi
le funzioni usciranno una volta restituite (implicitamente o esplicitamente).
Ruby
Non utilizzare exit()
o abort()
. Le funzioni HTTP devono restituire esplicitamente
una risposta sotto forma di stringa, mentre le funzioni basate su eventi usciranno
restituiscono un valore (implicitamente o esplicitamente).
PHP
Non utilizzare exit()
o die()
. Le funzioni HTTP devono restituire esplicitamente
una risposta sotto forma di stringa, mentre le funzioni basate su eventi usciranno
restituiscono un valore (implicitamente o esplicitamente).
Utilizza Sendgrid per inviare email
Le funzioni Cloud Run non consentono connessioni in uscita sulla porta 25, pertanto non puoi effettuare connessioni non sicure a un server SMTP. Il modo consigliato per inviare email è utilizzare SendGrid. Puoi trovare altre opzioni per inviare email Invio di email da un'istanza per Google 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 tue funzioni importano moduli, il tempo di caricamento per questi moduli può aumentare latenza di chiamata durante un avvio a freddo. Puoi ridurre questa latenza, oltre a il tempo necessario per il deployment della funzione, caricando correttamente le dipendenze non caricano dipendenze che la funzione non utilizza.
Utilizza le variabili globali per riutilizzare gli oggetti nelle chiamate future
Non è garantito che lo stato di una funzione Cloud Run verrà conservato per le chiamate future. Tuttavia, le funzioni Cloud Run spesso riutilizzano l'ambiente di esecuzione di un'invocazione 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 la chiamata di una funzione. Spostamento di questi oggetti dal corpo della funzione all'ambito globale può portare a miglioramenti significativi delle prestazioni. Nell'esempio che segue crea un oggetto pesante solo una volta per istanza di funzione e lo condivide chiamate di funzione che raggiungono l'istanza specificata:
Node.js
Python
Vai
Java
C#
Ruby
PHP
È particolarmente importante memorizzare nella cache connessioni di rete, riferimenti alle librerie e oggetti client API in ambito globale. Per alcuni esempi, consulta Ottimizzazione della rete.
Esegui l'inizializzazione lazy delle variabili globali
Se inizili le variabili a livello globale, il codice di inizializzazione verrà sempre eseguito tramite un'invocazione a freddo, aumentando la latenza della funzione.
In alcuni casi, questo causa timeout intermittenti per i servizi chiamati se non vengono gestiti correttamente in un blocco try
/catch
. Se
alcuni oggetti non vengono utilizzati in tutti i percorsi di codice, si consiglia di inizializzarli lentamente
on demand:
Node.js
Python
Vai
Java
C#
Ruby
PHP
Le funzioni PHP non possono conservare variabili tra le richieste. La campione degli ambiti sopra riportato utilizza il caricamento lento per memorizzare nella cache i valori delle variabili globali in un file.
Questo è particolarmente importante se definisci più funzioni in un unico file e le funzioni diverse utilizzano variabili diverse. A meno che non utilizzi l'inizializzazione dinamica, potresti sprecare risorse per variabili inizializzate, ma mai utilizzate.
Riduci gli avvii a freddo impostando un numero minimo di istanze
Per impostazione predefinita, le funzioni Cloud Run scalano il numero di istanze in base di richieste in entrata. Puoi modificare questo comportamento predefinito impostando un valore numero minimo di istanze che le funzioni Cloud Run devono tenere pronte per gestire le richieste. L'impostazione di un numero minimo di istanze riduce gli avvii a freddo della tua applicazione. Ti consigliamo di impostare un numero minimo di istanze se applicazione è sensibile alla latenza.
Per scoprire come impostare un numero minimo di istanze, consulta Utilizzare le istanze minime.
Risorse aggiuntive
Scopri di più sull'ottimizzazione del rendimento nel video "Google Cloud Performance Atlas" Tempo di avvio a freddo delle funzioni Cloud Run.