Questa pagina descrive i limiti scalabili e basati sull'utilizzo per Cloud Functions in base al piano tariffario Blaze con pagamento a consumo. Questi limiti si applicano ai progetti Firebase che eseguono il deployment delle funzioni nell'ambiente di runtime Node.js 10.
Il piano Blaze offre una quantità generosa di chiamate, tempo di calcolo e traffico internet senza costi. Tuttavia, i deployment delle funzioni comportano costi ridotti per lo spazio di archiviazione utilizzato per il contenitore della funzione. Per ulteriori informazioni, consulta le Domande frequenti su Firebase.
Le quote di Google Cloud Functions comprendono tre aree:
Limiti di risorse
Riguardano la quantità totale di risorse che le tue funzioni possono consumare.
Limiti di tempo
Riguardano i tempi di esecuzione.
Limitazioni di frequenza
Influiscono sulla frequenza con cui puoi chiamare l'API Cloud Functions per gestire le tue funzioni.
I diversi tipi di limiti sono descritti più dettagliatamente di seguito. Le differenze tra i limiti per Cloud Functions (1a gen.) e Cloud Functions (2a gen.) sono indicate ove applicabili.
Limiti di risorse
I limiti delle risorse influiscono sulla quantità totale di risorse che le funzioni possono utilizzare. L'ambito regionale è per progetto e ogni progetto ha i propri limiti.
Quota | Descrizione | Limit (1ª gen.) | Limite (2a generazione) | Aumentabile | Ambito |
---|---|---|---|---|---|
Numero di funzioni | Il numero totale di funzioni di cui può essere eseguito il deployment per area geografica | 1000 | 1000 meno il numero di servizi Cloud Run di cui è stato eseguito il deployment | No | per area geografica |
Dimensione massima del deployment | La dimensione massima di un singolo deployment di funzioni | 100 MB (compressi) per origini. 500 MB (non compressi) per origini più moduli. |
N/D | No | per funzione |
Dimensione massima della richiesta HTTP non compressa | Dati inviati a funzioni HTTP in una richiesta HTTP | 10 MB | 32 MB | No | per chiamata |
Dimensione massima della risposta HTTP non compressa | Dati inviati da funzioni HTTP in una risposta HTTP | 10 MB | 10 MB per le risposte dinamiche. 32 MB per le risposte non dinamiche. |
No | per chiamata |
Dimensione massima dell'evento per le funzioni basate su eventi | Dati inviati in eventi alle funzioni in background | 10 MB | 512 kB per gli eventi Eventarc. 10 MB per gli eventi precedenti. |
No | per evento |
Memoria massima della funzione | Quantità di memoria utilizzabile da ogni istanza di funzione | 8 GB | 32GiB | No | per funzione |
Memoria massima del progetto | Quantità di memoria, in byte, che un progetto può utilizzare. Viene misurata dalla somma totale della memoria richiesta dagli utenti nelle istanze di funzione in un periodo di 1 minuto. | Dipende dalla regione selezionata. Questo limite potrebbe essere superiore nelle regioni ad alta capacità o inferiore nelle regioni aperte di recente. | N/D | Sì | per progetto e regione |
CPU massima del progetto | Quantità di CPU, in milli vCPU, che un progetto può utilizzare. Viene misurata dalla somma totale della CPU richiesta dagli utenti nelle istanze di funzione in un periodo di 1 minuto. | Dipende dalla regione selezionata. Questo limite potrebbe essere superiore nelle regioni ad alta capacità o inferiore nelle regioni aperte di recente. | N/D | Sì | per progetto e regione |
Limiti di tempo
Quota | Descrizione | Limit (1ª gen.) | Limite (2a generazione) | Aumentabile | Ambito |
---|---|---|---|---|---|
Durata massima della funzione | La quantità massima di tempo in cui una funzione può essere eseguita prima di essere interrotta forzatamente | 540 secondi | 60 minuti per le funzioni HTTP. 9 minuti per le funzioni basate su eventi. |
No | per chiamata |
Limitazioni di frequenza
Quota | Descrizione | Limit (1ª gen.) | Limite (2a generazione) | Aumentabile | Ambito |
---|---|---|---|---|---|
Chiamate API (READ) | Chiamate per descrivere o elencare le funzioni tramite l'API Cloud Functions | 5000 per 100 secondi | 1200 per 60 secondi | Solo per la 1ª gen. | per progetto (1a generazione) per regione (2a generazione) |
Chiamate API (WRITE) | Chiamate per eseguire il deployment o eliminare funzioni tramite l'API Cloud Functions | 80 per 100 secondi | 60 per 60 secondi | No 1 | per progetto (1ª gen.) per regione (2ª gen.) |
Chiamate API (CALL) | Chiamate all'API "call" | 16 per 100 secondi | N/D | No 2 | per progetto |
Scalabilità
Le funzioni Cloud Functions richiamate da HTTP fanno lo scale up per gestire il traffico in entrata in tempi rapidi, mentre le funzioni in background lo fanno in modo più graduale. La capacità di una funzione di fare lo scale up è determinata da alcuni fattori, tra cui:
- Il tempo necessario per completare l'esecuzione di una funzione (le funzioni a breve esecuzione possono in genere scalare verticalmente per gestire più richieste in parallelo).
- Il tempo necessario per inizializzare una funzione con avvio a freddo.
- La frequenza di errori della tua funzione.
Fattori temporanei, come il carico a livello di area geografica e la capacità del data center.
Quote aggiuntive per le funzioni in background
Quota | Descrizione | Limite | Aumentabile | Ambito | Versione del prodotto |
---|---|---|---|---|---|
Numero massimo di chiamate simultanee | Il numero massimo di chiamate simultanee di una singola funzione Esempio: se la gestione di ogni evento richiede 100 secondi, la frequenza di chiamata sarà limitata in media a 30 al secondo |
3000 | Sì | per funzione | Solo 1a gen. |
Frequenza di chiamata massima | La frequenza massima di eventi gestiti da una singola funzione Esempio: se la gestione di un evento richiede 100 ms, la frequenza di chiamata sarà limitata a 1000 al secondo anche se in media vengono gestite in parallelo solo 100 richieste |
1000 al secondo | No | per funzione | Solo 1ª gen. |
Dimensione massima dei dati degli eventi simultanei | La dimensione totale massima degli eventi in entrata per le chiamate simultanee di una singola funzione Esempio: se gli eventi hanno una dimensione di 1 MB e la loro elaborazione richiede 10 secondi, la frequenza media sarà di 1 evento al secondo, perché l'undicesimo evento non verrà elaborato fino a quando non terminerà l'elaborazione di uno dei primi 10 eventi |
10 MB | No | per funzione | 1a e 2a gen. |
Velocità effettiva massima degli eventi in entrata | La velocità effettiva massima degli eventi in entrata in una singola funzione Esempio: se gli eventi hanno una dimensione di 1 MB, la frequenza di chiamata può essere al massimo di 10 al secondo, anche se le funzioni terminano entro 100 ms |
10 MB al secondo | No | per funzione | 1ª e 2ª gen. |
Raggiungimento di un limite di quota
Quando una funzione consuma completamente una risorsa allocata, questa non sarà più disponibile fino a quando la quota non viene aggiornata o aumentata. Ciò può causare il blocco della funzione e di tutte le altre funzioni dello stesso progetto fino all'aggiornamento o all'aumento della quota. Una funzione restituisce un codice di errore HTTP 500 quando una delle risorse ha superato la quota e la funzione non può essere eseguita.
Per aumentare le quote oltre i valori predefiniti elencati qui, vai alla pagina Quote di Cloud Functions, seleziona le quote che vuoi modificare, fai clic su MODIFICA QUOTE, fornisci le tue informazioni utente se richieste e immetti il nuovo limite per ogni quota selezionata.
Limiti di quota per il deployment dell'interfaccia a riga di comando di Firebase
Per ogni funzione di cui viene eseguito il deployment tramite l'interfaccia a riga di comando di Firebase, sono interessati questi tipi di limiti di frequenza e di tempo:
- Chiamate API (READ): 1 chiamata per deployment, indipendentemente dal numero di funzioni
- Limite: 5000 ogni 100 secondi
- Chiamate API (WRITE): 1 chiamata per funzione
- Limite: 80 ogni 100 secondi
Consulta anche il riferimento all'interfaccia a riga di comando di Firebase.