Puoi eseguire il deployment, eliminare e modificare le funzioni utilizzando i comandi dell'interfaccia a riga di comando Firebase o impostando le opzioni di runtime nel codice sorgente delle funzioni.
Esegui il deployment delle funzioni
Per eseguire il deployment delle funzioni, esegui questo comando dell'interfaccia a riga di comando Firebase:
firebase deploy --only functions
Per impostazione predefinita, l'interfaccia a riga di comando Firebase esegue il deployment di tutte le funzioni all'interno dell'origine contemporaneamente. Se il progetto contiene più di 5 funzioni, ti consigliamo di utilizzare il flag --only con nomi di funzioni specifici per eseguire il deployment solo delle funzioni che hai modificato. Il deployment di funzioni specifiche in questo modo velocizza il processo di deployment e ti aiuta a evitare di raggiungere le quote di deployment. Ad esempio:
firebase deploy --only functions:addMessage,functions:makeUppercase
Quando esegui il deployment di un numero elevato di funzioni, potresti superare la quota standard e ricevere messaggi di errore HTTP 429 o 500. Per risolvere il problema, esegui il deployment delle funzioni in gruppi di massimo 10.
Per l'elenco completo dei comandi disponibili, consulta il riferimento all'interfaccia a riga di comando Firebase.
Per impostazione predefinita, l'interfaccia a riga di comando Firebase cerca il codice sorgente nella cartella functions/. Se preferisci, puoi organizzare le funzioni in codebase o in più set di file.
Esegui la pulizia degli artefatti di deployment
Nell'ambito del deployment delle funzioni, le immagini container vengono generate e archiviate in Artifact Registry. Queste immagini non sono necessarie per l'esecuzione delle funzioni di cui è stato eseguito il deployment; Cloud Functions recupera e conserva una copia dell'immagine durante il deployment iniziale, ma gli artefatti archiviati non sono necessari per il funzionamento della funzione in fase di runtime.
Sebbene queste immagini container siano spesso di piccole dimensioni, possono accumularsi nel tempo e contribuire ai costi di archiviazione. Potresti preferire conservarli per un periodo di tempo se prevedi di ispezionare gli artefatti creati o di eseguire analisi delle vulnerabilità dei container.
Per aiutarti a gestire i costi di archiviazione, l'interfaccia a riga di comando Firebase 14.0.0 e versioni successive consente di configurare una policy di pulizia di Artifact Registry per i repository che archiviano gli artefatti di deployment dopo ogni deployment delle funzioni.
Puoi configurare o modificare manualmente una policy di pulizia utilizzando il comando functions:artifacts:setpolicy:
firebase functions:artifacts:setpolicy
Per impostazione predefinita, questo comando configura Artifact Registry in modo che elimini automaticamente le immagini container più vecchie di un giorno. In questo modo, si ottiene un ragionevole equilibrio tra la riduzione al minimo dei costi di archiviazione e la possibilità di ispezionare le build recenti.
Puoi personalizzare il periodo di conservazione utilizzando l'opzione --days:
firebase functions:artifacts:setpolicy --days 7 # Delete images older than 7 days
Se esegui il deployment delle funzioni in più regioni, puoi configurare una policy di pulizia per una località specifica utilizzando l'opzione --location:
$ firebase functions:artifacts:setpolicy --location europe-west1
Disattiva la pulizia degli artefatti
Se preferisci gestire manualmente la pulizia delle immagini o se non vuoi che vengano eliminate immagini, puoi disattivare completamente le policy di pulizia:
$ firebase functions:artifacts:setpolicy --none
Questo comando rimuove qualsiasi policy di pulizia esistente configurata dall'interfaccia a riga di comando Firebase e impedisce a Firebase di configurare una policy di pulizia dopo i deployment delle funzioni.
Elimina funzioni
Puoi eliminare le funzioni di cui hai eseguito il deployment in precedenza nei seguenti modi:
- esplicitamente nell'interfaccia a riga di comando Firebase con
functions:delete - esplicitamente nella console Google Cloud.
- In modo implicito, rimuovendo la funzione dall'origine prima del deployment.
Tutte le operazioni di eliminazione richiedono una conferma prima di rimuovere la funzione dalla produzione.
L'eliminazione esplicita delle funzioni nell'interfaccia a riga di comando Firebase supporta più argomenti e gruppi di funzioni e consente di specificare una funzione in esecuzione in una determinata regione. Inoltre, puoi ignorare la richiesta di conferma.
Elimina tutte le funzioni che corrispondono al nome specificato in tutte le regioni:
firebase functions:delete FUNCTION-1_NAME
Elimina una funzione specificata in esecuzione in una regione non predefinita:
firebase functions:delete FUNCTION-1_NAME --region REGION_NAME
Elimina più di una funzione:
firebase functions:delete FUNCTION-1_NAME FUNCTION-2_NAME
Elimina un gruppo di funzioni specificato:
firebase functions:delete GROUP_NAME
Ignora la richiesta di conferma:
firebase functions:delete FUNCTION-1_NAME --force
Con l'eliminazione implicita delle funzioni, firebase deploy analizza l'origine e rimuove dalla produzione tutte le funzioni che sono state rimosse dal file.
Modifica il nome, la regione o il trigger di una funzione
Se stai rinominando o modificando le regioni o il trigger per le funzioni che gestiscono il traffico di produzione, segui i passaggi descritti in questa sezione per evitare di perdere eventi durante la modifica. Prima di seguire questi passaggi, assicurati che la tua funzione sia idempotente, poiché durante la modifica verranno eseguite contemporaneamente sia la nuova versione che la versione precedente della funzione.
Rinomina una funzione
Per rinominare una funzione, crea una nuova versione rinominata della funzione nell'origine, quindi esegui due comandi di deployment separati. Il primo comando esegue il deployment della funzione con nome, mentre il secondo comando rimuove la versione di cui è stato eseguito il deployment in precedenza. Ad esempio, se hai un webhook attivato tramite HTTP che vuoi rinominare, modifica il codice come segue:
Node.js
// before
const {onRequest} = require('firebase-functions/v2/https');
exports.webhook = onRequest((req, res) => {
res.send("Hello");
});
// after
const {onRequest} = require('firebase-functions/v2/https');
exports.webhookNew = onRequest((req, res) => {
res.send("Hello");
});
Python
# before
from firebase_functions import https_fn
@https_fn.on_request()
def webhook(req: https_fn.Request) -> https_fn.Response:
return https_fn.Response("Hello world!")
# after
from firebase_functions import https_fn
@https_fn.on_request()
def webhook_new(req: https_fn.Request) -> https_fn.Response:
return https_fn.Response("Hello world!")
Quindi esegui questi comandi per eseguire il deployment della nuova funzione:
# Deploy new function firebase deploy --only functions:webhookNew # Wait until deployment is done; now both functions are running # Delete webhook firebase functions:delete webhook
Modifica la regione o le regioni di una funzione
Se modifichi le regioni specificate per una funzione che gestisce il traffico di produzione, puoi evitare la perdita di eventi seguendo questi passaggi nell'ordine indicato:
- Rinomina la funzione e modifica la regione o le regioni come preferisci.
- Esegui il deployment della funzione rinominata, in modo che lo stesso codice venga eseguito temporaneamente in entrambi i gruppi di regioni.
- Elimina la funzione precedente.
Ad esempio, se hai una funzione attivata da Cloud Firestore di cui è attualmente stato eseguito il deployment in us-central1 e vuoi eseguirne la migrazione in asia-northeast1, devi prima modificare il codice sorgente per rinominare la funzione e rivedere la regione.
Node.js
// before
exports.firestoreTrigger = onDocumentCreated(
"my-collection/{docId}",
(event) => {},
);
// after
exports.firestoreTriggerAsia = onDocumentCreated(
{
document: "my-collection/{docId}",
region: "asia-northeast1",
},
(event) => {},
);
Il codice aggiornato deve specificare il filtro degli eventi corretto (in questo caso document) insieme alla regione. Per saperne di più, consulta Località Cloud Functions.
Python
# Before
@firestore_fn.on_document_created("my-collection/{docId}")
def firestore_trigger(event):
pass
# After
@firestore_fn.on_document_created("my-collection/{docId}",
region="asia-northeast1")
def firestore_trigger_asia(event):
pass
Quindi esegui il deployment con il comando:
firebase deploy --only functions:firestoreTriggerAsia
Ora sono in esecuzione due funzioni identiche: firestoreTrigger è in esecuzione in us-central1 e firestoreTriggerAsia è in esecuzione in asia-northeast1.
Poi, elimina firestoreTrigger:
firebase functions:delete firestoreTrigger
Ora esiste una sola funzione, firestoreTriggerAsia, in esecuzione in asia-northeast1.
Modifica il tipo di trigger di una funzione
Man mano che sviluppi il deployment di Cloud Functions for Firebase nel tempo, potresti dover modificare il tipo di trigger di una funzione per vari motivi. Ad esempio, potresti voler passare da un tipo di evento Firebase Realtime Database o Cloud Firestore a un altro.
Non è possibile modificare il tipo di evento di una funzione semplicemente modificando il codice sorgente ed eseguendo firebase deploy. Per evitare errori, modifica il tipo di trigger di una funzione seguendo questa procedura:
- Modifica il codice sorgente per includere una nuova funzione con il tipo di trigger desiderato.
- Esegui il deployment della funzione, il che comporta l'esecuzione temporanea sia della funzione precedente che di quella nuova.
- Elimina esplicitamente la vecchia funzione dalla produzione utilizzando l'interfaccia a riga di comando Firebase.
Ad esempio, se avevi una funzione che veniva attivata quando un oggetto veniva eliminato, ma poi hai attivato il controllo delle versioni degli oggetti e vuoi sottoscrivere l'evento di archiviazione, rinomina prima la funzione e modificala in modo che abbia il nuovo tipo di trigger.
Node.js
// before
const {onObjectDeleted} = require("firebase-functions/v2/storage");
exports.objectDeleted = onObjectDeleted((event) => {
// ...
});
// after
const {onObjectArchived} = require("firebase-functions/v2/storage");
exports.objectArchived = onObjectArchived((event) => {
// ...
});
Python
# before
from firebase_functions import storage_fn
@storage_fn.on_object_deleted()
def object_deleted(event):
# ...
# after
from firebase_functions import storage_fn
@storage_fn.on_object_archived()
def object_archived(event):
# ...
Quindi, esegui i comandi seguenti per creare la nuova funzione prima di eliminare quella precedente:
# Create new function objectArchived firebase deploy --only functions:objectArchived # Wait until deployment is done; now both objectDeleted and objectArchived are running # Delete objectDeleted firebase functions:delete objectDeleted
Imposta le opzioni di runtime
Cloud Functions for Firebase consente di selezionare opzioni di runtime come la versione di runtime Node.js e il timeout, l'allocazione della memoria e il numero minimo/massimo di istanze della funzione per funzione.
Come best practice, queste opzioni (ad eccezione della versione di Node.js) devono essere impostate su un oggetto di configurazione all'interno del codice della funzione. Questo oggetto RuntimeOptions è la fonte di verità per le opzioni di runtime della funzione e sostituirà le opzioni impostate utilizzando qualsiasi altro metodo (ad esempio la console Google Cloud o gcloud CLI).
Se il tuo workflow di sviluppo prevede l'impostazione manuale delle opzioni di runtime utilizzando la console Google Cloud o gcloud CLI e non vuoi che questi valori vengano sovrascritti a ogni deployment, imposta l'opzione preserveExternalChanges su true. Con questa opzione impostata su true, Firebase unisce le opzioni di runtime impostate nel codice con le impostazioni della versione attualmente di cui è stato eseguito il deployment della funzione con la seguente priorità:
- L'opzione è impostata nel codice delle funzioni: esegui l'override delle modifiche esterne.
- L'opzione è impostata su
RESET_VALUEnel codice delle funzioni: esegui l'override delle modifiche esterne con il valore predefinito. - L'opzione non è impostata nel codice delle funzioni, ma è impostata nella funzione attualmente di cui è stato eseguito il deployment: utilizza l'opzione specificata nella funzione di cui è stato eseguito il deployment.
L'utilizzo dell'opzione preserveExternalChanges: true non è consigliato per la maggior parte degli scenari, perché il codice non sarà più l'unica fonte di attendibilità per le opzioni di runtime delle funzioni. Se lo utilizzi, controlla la console Google Cloud o utilizza gcloud CLI per visualizzare la configurazione completa di una funzione.
Imposta la versione di Node.js
L'SDK Firebase per Cloud Functions consente di selezionare il runtime Node.js. Puoi scegliere di eseguire tutte le funzioni di un progetto esclusivamente nell'ambiente di runtime corrispondente a una di queste versioni di Node.js supportate:
- Node.js 22
- Node.js 20
- Node.js 18 (deprecato)
Le versioni 14 e 16 di Node.js sono state ritirate all'inizio del 2025. Il deployment con queste versioni è disabilitato. Consulta la pianificazione dell'assistenza per informazioni importanti sull'assistenza continua per queste versioni di Node.js.
Per impostare la versione di Node.js:
Puoi impostare la versione nel campo engines del file package.json creato nella directory functions/ durante l'inizializzazione.
Ad esempio, per utilizzare solo la versione 20, modifica questa riga in package.json:
"engines": {"node": "20"}
Se utilizzi il gestore di pacchetti Yarn o hai altri requisiti specifici per il campo engines, puoi impostare il runtime per l'SDK Firebase per Cloud Functions in firebase.json:
{
"functions": {
"runtime": "nodejs20" // or nodejs22
}
}
L'interfaccia a riga di comando utilizza il valore impostato in firebase.json anziché qualsiasi valore o intervallo impostato separatamente in package.json.
Esegui l'upgrade del runtime Node.js
Per eseguire l'upgrade del runtime Node.js:
- Assicurati che il tuo progetto sia nel piano tariffario Blaze.
- Assicurati di utilizzare l'interfaccia a riga di comando Firebase v11.18.0 o versioni successive.
- Modifica il valore
enginesnel filepackage.jsoncreato nella directoryfunctions/durante l'inizializzazione. Ad esempio, se esegui l'upgrade dalla versione 18 alla versione 20, la voce dovrebbe avere il seguente aspetto:"engines": {"node": "20"} - Facoltativamente, testa le modifiche utilizzando Firebase Local Emulator Suite.
- Rifai il deployment di tutte le funzioni.
Scegli un sistema di moduli Node.js
Il sistema di moduli predefinito in Node.js è CommonJS (CJS), ma le versioni attuali di Node.js supportano anche i moduli ECMAScript (ESM). Cloud Functions supporta entrambi.
Per impostazione predefinita, le funzioni utilizzano CommonJS. Ciò significa che le importazioni e le esportazioni hanno questo aspetto:
const {onRequest} = require("firebase-functions/https");
exports.helloWorld = onRequest(async (req, res) => res.send("Hello from Firebase!"));
Per utilizzare invece ESM, imposta il campo "type": "module" nel file package.json:
{
...
"type": "module",
...
}
Una volta impostato, utilizza la sintassi ESM import e export:
import {onRequest} from "firebase-functions/https";
export const helloWorld = onRequest(async (req, res) => res.send("Hello from Firebase!"));
Entrambi i sistemi di moduli sono completamente supportati. Puoi scegliere quella più adatta al tuo progetto. Scopri di più nella documentazione di Node.js sui moduli.
Imposta la versione di Python
L'SDK Firebase per Cloud Functions versioni 12.0.0 e successive consente la selezione del runtime Python. Imposta la versione runtime in firebase.json come mostrato:
{
"functions": {
"runtime": "python310" // or python311
}
}
Controlla il comportamento di scalabilità
Per impostazione predefinita, Cloud Functions for Firebase scala il numero di istanze in esecuzione in base al numero di richieste in entrata, con la possibilità di fare lo scale down fino a zero istanze in periodi di traffico ridotto. Tuttavia, se la tua app richiede una latenza ridotta e vuoi limitare il numero di avvii a freddo, puoi modificare questo comportamento predefinito specificando un numero minimo di istanze di container da mantenere in uso e pronte per gestire le richieste.
Analogamente, puoi impostare un numero massimo per limitare lo scale up delle istanze in risposta alle richieste in entrata. Utilizza questa impostazione per controllare i costi o per limitare il numero di connessioni a un servizio di supporto, ad esempio un database.
Utilizzando queste impostazioni insieme all'impostazione di concorrenza per istanza (nuova nella 2ª gen.), puoi controllare e ottimizzare il comportamento di scalabilità delle tue funzioni. La natura dell'applicazione e della funzione determinerà quali impostazioni sono più convenienti e genereranno le prestazioni migliori.
Per alcune app con traffico ridotto, un'opzione CPU inferiore senza concorrenza multipla è ottimale. Per altri utenti per i quali gli avvii a freddo sono un problema critico, l'impostazione di una concorrenza elevata e di un numero minimo di istanze significa che un insieme di istanze viene sempre mantenuto attivo per gestire picchi di traffico elevati.
Per le app di dimensioni ridotte che ricevono pochissimo traffico, l'impostazione di un numero ridotto di istanze massime con un'elevata contemporaneità consente all'app di gestire i picchi di traffico senza incorrere in costi eccessivi. Tuttavia, tieni presente che se il numero massimo di istanze è impostato su un valore troppo basso, le richieste potrebbero essere ignorate quando viene raggiunto il limite.
Consenti richieste in parallelo
In Cloud Functions for Firebase (1ª gen.), ogni istanza poteva gestire una richiesta alla volta, quindi il comportamento di scalabilità veniva impostato solo con le impostazioni del numero minimo e massimo di istanze.
Oltre a controllare il numero di istanze, in Cloud Functions for Firebase (2ª gen.) puoi controllare il numero di richieste che ogni istanza può gestire contemporaneamente con l'opzione concurrency. Il valore predefinito per la concorrenza è 80, ma puoi impostarlo su qualsiasi numero intero compreso tra 1 e 1000.
Le funzioni con impostazioni di contemporaneità più elevate possono assorbire i picchi di traffico senza avvio a freddo, perché ogni istanza probabilmente ha un margine di sicurezza. Se un'istanza è configurata per gestire fino a 50 richieste in parallelo, ma al momento ne gestisce solo 25, può gestire un picco di 25 richieste aggiuntive senza richiedere l'avvio a freddo di una nuova istanza. Al contrario, con un'impostazione di contemporaneità pari a 1, questo picco di richieste potrebbe comportare 25 avvii a freddo.
Questo scenario semplificato dimostra i potenziali vantaggi in termini di efficienza della concorrenza. In realtà, il comportamento di scalabilità per ottimizzare l'efficienza e ridurre gli avvii a freddo con la contemporaneità è più complesso. La concorrenza in Cloud Functions for Firebase di 2ª gen. è basata su Cloud Run e segue le regole di Cloud Run per la scalabilità automatica delle istanze di container.
Quando sperimenti impostazioni di contemporaneità più elevate in Cloud Functions for Firebase (2ª gen.), tieni presente quanto segue:
- Impostazioni di contemporaneità più elevate potrebbero richiedere più CPU e RAM per prestazioni ottimali fino a raggiungere un limite pratico. Ad esempio, una funzione che esegue un'elaborazione di immagini o video complessa potrebbe non disporre delle risorse necessarie per gestire 1000 richieste in parallelo, anche se le impostazioni di CPU e RAM sono massimizzate.
- Poiché Cloud Functions for Firebase (2ª gen.) è basato su Cloud Run, puoi fare riferimento anche alle indicazioni di Google Cloud per ottimizzare la contemporaneità.
- Assicurati di testare accuratamente la multiconcorrenza in un ambiente di test prima di passare alla multiconcorrenza in produzione.
Mantieni un numero minimo di istanze attive
Puoi impostare un numero minimo di istanze per una funzione nel codice sorgente. Ad esempio, questa funzione imposta un numero minimo di 5 istanze da mantenere attive:
Node.js
const { onCall } = require("firebase-functions/v2/https");
exports.getAutocompleteResponse = onCall(
{
// Keep 5 instances warm for this latency-critical function
minInstances: 5,
},
(event) => {
// Autocomplete user’s search term
}
);
Python
@https_fn.on_call(min_instances=5)
def get_autocomplete_response(event: https_fn.CallableRequest) -> https_fn.Response:
Ecco alcuni aspetti da considerare quando imposti un valore per il numero minimo di istanze:
- Se Cloud Functions for Firebase scala la tua app oltre l'impostazione, si verificherà un avvio a freddo per ogni istanza al di sopra di questa soglia.
- Gli avvii a freddo hanno l'effetto più grave sulle app con picchi di traffico. Se la tua app ha un traffico con picchi e imposti un valore sufficientemente alto da ridurre gli avvii a freddo a ogni aumento del traffico, vedrai una latenza notevolmente ridotta. Per le app con traffico costante, è improbabile che gli avvii a freddo influiscano gravemente sulle prestazioni.
L'impostazione di istanze minime può essere utile per gli ambienti di produzione, ma in genere deve essere evitata negli ambienti di test. Per fare lo scale down a zero nel progetto di test, ma ridurre comunque gli avvii a freddo nel progetto di produzione, puoi impostare un valore minimo di istanze nella configurazione parametrizzata:
Node.js
const { onRequest } = require('firebase-functions/https'); const { defineInt, defineString } = require('firebase-functions/params'); // Define some parameters const minInstancesConfig = defineInt('HELLO_WORLD_MININSTANCES'); const welcomeMessage = defineString('WELCOME_MESSAGE'); // To use configured parameters inside the config for a function, provide them // directly. To use them at runtime, call .value() on them. export const helloWorld = onRequest( { minInstances: minInstancesConfig }, (req, res) => { res.send(`${welcomeMessage.value()}! I am a function.`); } );Python
MIN_INSTANCES = params.IntParam("HELLO_WORLD_MININSTANCES") WELCOME_MESSAGE = params.StringParam("WELCOME_MESSAGE") @https_fn.on_request(min_instances=MIN_INSTANCES.value()) def get_autocomplete_response(event: https_fn.Request) -> https_fn.Response: return https_fn.Response(f"{WELCOME_MESSAGE.value()} I'm a function.")
Limita il numero massimo di istanze per una funzione
Puoi impostare un valore per il numero massimo di istanze nel codice sorgente della funzione. Ad esempio, questa funzione imposta un limite di 100 istanze per non sovraccaricare un ipotetico database legacy:
Node.js
const { onMessagePublished } = require("firebase-functions/v2/pubsub");
exports.mirrorevents = onMessagePublished(
{ topic: "topic-name", maxInstances: 100 },
(event) => {
// Connect to legacy database
}
);
Python
@pubsub_fn.on_message_published(topic="topic-name", max_instances=100)
def mirrorevents(event: pubsub_fn.CloudEvent):
# Connect to legacy database
Se una funzione HTTP viene scalata fino al limite massimo di istanze, le nuove richieste vengono messe in coda per 30 secondi e poi rifiutate con un codice di risposta 429 Too Many Requests se nel frattempo non è disponibile alcuna istanza.
Per scoprire di più sulle best practice per l'utilizzo delle impostazioni del numero massimo di istanze, consulta queste best practice per l'impostazione del numero massimo di istanze.
Imposta un service account
I service account predefiniti per le funzioni dispongono di un ampio set di autorizzazioni per consentirti di interagire con altri servizi Firebase e Google Cloud:
- Funzioni di 2ª gen.: PROJECT_NUMBER-compute@developer.gserviceaccount.com (denominato Service account predefinito Compute Engine)
- Funzioni di 1ª gen.: PROJECT_ID@
appspot.gserviceaccount.com (denominato Service account predefinito di App Engine)
Potresti voler eseguire l'override del service account predefinito e limitare una funzione alle risorse esatte necessarie. Puoi farlo creando un service account personalizzato e assegnandolo alla funzione appropriata utilizzando il valore di configurazione serviceAccount:
const { onRequest } = require("firebase-functions/https");
exports.helloWorld = onRequest(
{
// This function doesn't access other Firebase project resources, so it uses a limited service account.
serviceAccount:
"my-limited-access-sa@", // or prefer the full form: "my-limited-access-sa@my-project.iam.gserviceaccount.com"
},
(request, response) => {
response.send("Hello from Firebase!");
},
);
Se vuoi impostare lo stesso service account per tutte le tue funzioni, puoi farlo con la funzione setGlobalOptions.
Imposta il timeout e l'allocazione della memoria
In alcuni casi, le tue funzioni potrebbero avere requisiti speciali per un valore di timeout lungo o un'allocazione di memoria elevata. Puoi impostare questi valori nella consoleGoogle Cloud o nel codice sorgente della funzione (solo Firebase), utilizzando valori di timeout entro questi limiti di durata massima:
- Funzioni HTTP e richiamabili: 3600 secondi (60 minuti)
- Funzioni pianificate/della coda di attività: 1800 secondi (30 minuti)
- Altre funzioni basate su eventi: 540 secondi (9 minuti)
Per impostare l'allocazione della memoria e il timeout nel codice sorgente delle funzioni, utilizza le opzioni globali per la memoria e i secondi di timeout per personalizzare la macchina virtuale che esegue le tue funzioni. Ad esempio, questa funzione Cloud Storage utilizza 1 GiB di memoria e scade dopo 300 secondi:
Node.js
exports.convertLargeFile = onObjectFinalized({
timeoutSeconds: 300,
memory: "1GiB",
}, (event) => {
// Do some complicated things that take a lot of memory and time
});
Python
@storage_fn.on_object_finalized(timeout_sec=300, memory=options.MemoryOption.GB_1)
def convert_large_file(event: storage_fn.CloudEvent):
# Do some complicated things that take a lot of memory and time.
Per impostare l'allocazione della memoria e il timeout nella console Google Cloud:
- Nella console Google Cloud, seleziona Cloud Functions for Firebase dal menu a sinistra.
- Seleziona una funzione facendo clic sul suo nome nell'elenco delle funzioni.
- Fai clic sull'icona Modifica nel menu in alto.
- Seleziona un'allocazione della memoria dal menu a discesa Memoria allocata.
- Fai clic su Altro per visualizzare le opzioni avanzate e inserisci un numero di secondi nella casella di testo Timeout.
- Fai clic su Salva per aggiornare la funzione.
Esegui l'override delle impostazioni predefinite della CPU
Fino a 2 GB di allocazione della memoria, ogni funzione in Cloud Functions for Firebase (2ª gen.) utilizza per impostazione predefinita una CPU, che poi aumenta a 2 CPU per 4 e 8 GB. Tieni presente che questo comportamento è significativamente diverso da quello predefinito della 1ª gen. in modi che potrebbero comportare costi leggermente più elevati per le funzioni con memoria ridotta, come indicato nella tabella seguente:
| RAM allocata | CPU predefinita della versione 1 (frazionaria) | CPU predefinita della versione 2 | Aumento di prezzo per ms |
|---|---|---|---|
| 128 MB | 1/12 | 1 | 10,5x |
| 256 MB | 1/6 | 1 | 5,3x |
| 512 MB | 1/3 | 1 | 2,7x |
| 1 GB | 7/12 | 1 | 1,6x |
| 2 GB | 1 | 1 | 1x |
| 4 GB | 2 | 2 | 1x |
| 8 GB | 2 | 2 | 1x |
| 16 GB | n/d | 4 | n/d |
Se preferisci il comportamento di 1ª gen. per le funzioni di 2ª gen., imposta i valori predefiniti di 1ª gen. come opzione globale:
Node.js
// Turn off Firebase defaults
setGlobalOptions({ cpu: 'gcf_gen1' });
Python
# Use 1st gen behavior
set_global_options(cpu="gcf_gen1")
Per le funzioni che richiedono un utilizzo intensivo della CPU, la 2ª gen offre la flessibilità di configurare una CPU aggiuntiva. Puoi potenziare la CPU per ogni funzione, come mostrato di seguito:
Node.js
// Boost CPU in a function:
export const analyzeImage = onObjectFinalized({ cpu: 2 }, (event) => {
// computer vision goes here
});
Python
# Boost CPU in a function:
@storage_fn.on_object_finalized(cpu=2)
def analyze_image(event: storage_fn.CloudEvent):
# computer vision goes here