Cette page détaille les limites évolutives basées sur l'utilisation pour Cloud Functions avec le paiement à l'usage Blaze. Ces limites s'appliquent Projets Firebase qui déploient des fonctions dans l'environnement d'exécution Node.js 10
Le forfait Blaze offre des quantités généreuses d'appels, de temps de calcul et de trafic Internet sans frais. Toutefois, les déploiements de fonctions entraînent des frais à petite échelle pour l'espace de stockage utilisé pour le conteneur de la fonction. Pour en savoir plus, consultez les questions fréquentes sur Firebase.
Les quotas relatifs à Google Cloud Functions sont divisés en trois catégories :
Limites de ressources
Ces limites concernent la quantité totale de ressources que vos fonctions peuvent consommer.
Limites de durée
Ces limites concernent les durées d'exécution.
Limites de débit
Ces limites concernent la fréquence à laquelle vous pouvez appeler l'API Cloud Functions pour gérer vos fonctions.
Les différents types de limites sont décrits plus en détail ci-dessous. Les différences entre les limites de Cloud Functions (1st gen) et de Cloud Functions (2nd gen) sont indiquées, le cas échéant.
Limites de ressources
Les limites de ressources affectent la quantité totale de ressources que vos fonctions peuvent consommer. Le champ d'application régional est défini par projet, et chaque projet conserve ses propres limites.
Quota | Description | Limite (1re génération) | Limite (2e génération) | Augmentation possible | Champ d'application |
---|---|---|---|---|---|
Nombre de fonctions | Nombre total de fonctions pouvant être déployées par région | 1 000 | 1 000 moins le nombre de services Cloud Run déployés | Non | Par région |
Taille maximale des déploiements | Taille maximale d'un déploiement d'une seule fonction | 100 Mo (compressé) pour les sources 500 Mo (non compressé) pour les sources et les modules |
N/A | Non | Par fonction |
Taille maximale des requêtes HTTP non compressées | Données envoyées aux fonctions HTTP dans une requête HTTP | 10 Mo | 32 Mo | Non | Par appel |
Taille maximale des réponses HTTP non compressées | Données envoyées à partir de fonctions HTTP dans une réponse HTTP | 10 Mo | 10 Mo pour les réponses en streaming. 32 Mo pour les réponses sans streaming. |
Non | Par appel |
Taille maximale des événements pour les fonctions basées sur des événements | Données envoyées dans des événements aux fonctions d'arrière-plan | 10 Mo | 512 Ko pour les événements Eventarc. 10 Mo pour les anciens événements. |
Non | Par événement |
Mémoire maximale de la fonction | Quantité de mémoire que chaque instance de fonction peut utiliser | 8 Gio | 32 Gio | Non | Par fonction |
Mémoire maximale du projet | Quantité de mémoire, en octets, qu'un projet peut utiliser. Elle est mesurée par la somme totale de mémoire demandée par l'utilisateur pour toutes les instances de fonction sur une période d'une minute. | Dépend de la région sélectionnée. Cette limite peut être supérieure dans les régions disposant d'une grande capacité ou inférieure dans les régions récemment ouvertes. | N/A | Oui | Par projet et par région |
CPU maximal du projet | Quantité de processeurs, en millièmes de vCPU, qu'un projet peut utiliser. Elle est mesurée par la somme totale de processeur demandé par l'utilisateur pour toutes les instances de fonction sur une période d'une minute. | Dépend de la région sélectionnée. Cette limite peut être supérieure dans les régions disposant d'une grande capacité ou inférieure dans les régions récemment ouvertes. | N/A | Oui | Par projet et par région |
Limites de durée
Quota | Description | Limite (1re génération) | Limite (2e génération) | Augmentation possible | Champ d'application |
---|---|---|---|---|---|
Durée maximale de la fonction | Durée maximale d'exécution d'une fonction avant son arrêt automatique | 540 secondes | 60 minutes pour les fonctions HTTP. 9 minutes pour les fonctions basées sur des événements. |
Non | Par appel |
Limites de débit
Quota | Description | Limite (1re génération) | Limite (2e génération) | Augmentation possible | Champ d'application |
---|---|---|---|---|---|
Appels d'API (LECTURE) | Appels pour décrire ou répertorier des fonctions via l'API Cloud Functions | 5 000 pour 100 secondes | 1 200 pour 60 secondes | Uniquement pour la 1re génération | Par projet (1re génération) par région (2e génération) |
Appels d'API (ÉCRITURE) | Appels pour déployer ou supprimer des fonctions via l'API Cloud Functions | 80 pour 100 secondes | 60 pour 60 secondes | Non1 | Par projet (1re génération) par région (2e génération) |
Appels d'API (APPEL) | Appels à l'API d'appel | 16 pour 100 secondes | N/A | Non2 | Par projet |
Évolutivité
Les fonctions Cloud Functions appelées par des requêtes HTTP évoluent rapidement à la hausse pour gérer le trafic entrant, tandis que les fonctions d'arrière-plan s'adaptent plus progressivement. La capacité d'une fonction à évoluer à la hausse est déterminée par plusieurs facteurs, parmi lesquels :
- Temps nécessaire pour l'exécution d'une fonction (les fonctions de courte durée pouvant généralement évoluer à la hausse pour traiter plus de requêtes simultanées)
- Temps nécessaire à l'initialisation d'une fonction à partir d'un démarrage à froid
- Taux d'erreur de la fonction
Facteurs temporaires, tels que la charge régionale et la capacité du centre de données
Quotas supplémentaires pour les fonctions d'arrière-plan
Quota | Description | Limite | Augmentation possible | Champ d'application | Version du produit |
---|---|---|---|---|---|
Nombre maximal d'appels simultanés | Nombre maximal d'appels simultanés pour une seule fonction Exemple : si le traitement d'un événement prend 100 secondes, la fréquence d'appels sera limitée à 30 par seconde en moyenne. |
3 000 | Oui | Par fonction | 1re génération uniquement |
Fréquence maximale d'appels | Fréquence maximale d'événements traités par une seule fonction Exemple : si le traitement d'un événement prend 100 ms, la fréquence d'appels sera limitée à 1 000 par seconde, même si seulement 100 requêtes, en moyenne, sont traitées en parallèle. |
1 000 par seconde | Non | Par fonction | 1re génération uniquement |
Taille maximale des données d'événements simultanés | Taille totale maximale des événements entrants pour des appels simultanés d'une
seule fonction Exemple : si la taille des événements est de 1 Mo et que leur traitement prend 10 secondes, le taux moyen sera d'un événement par seconde, car le traitement du 11e événement ne commencera pas tant que celui de l'un des 10 premiers événements ne sera pas terminé. |
10 Mo | Non | Par fonction | 1re et 2e générations |
Débit maximal des événements entrants | Débit maximal des événements entrants vers une seule fonction Exemple : si la taille des événements est de 1 Mo, la fréquence d'appels peut être au maximum de 10 par seconde, même si les fonctions s'exécutent en moins de 100 ms. |
10 Mo par seconde | Non | Par fonction | 1re et 2e générations |
Limite de quota atteinte
Lorsqu'une fonction consomme toute une ressource allouée, la ressource devient indisponible jusqu'à ce que le quota soit renouvelé ou augmenté. Cela peut signifier que votre fonction et toutes les autres présentes dans le même projet ne seront pas opérationnelles d'ici là. Une fonction renvoie un code d'erreur HTTP 500 lorsqu'elle ne peut pas être exécutée en raison du dépassement du quota de l'une des ressources.
Pour augmenter les quotas par défaut indiqués dans ce document, accédez à la page Quotas Cloud Functions et sélectionnez ceux que vous souhaitez modifier. Cliquez sur MODIFIER LES QUOTAS. Si vous y êtes invité, indiquez vos informations utilisateur. Enfin, saisissez une nouvelle limite pour chaque quota sélectionné.
Limites de quota pour le déploiement de la CLI Firebase
Pour chaque fonction que la CLI Firebase déploie, les limites de débit et de temps suivantes sont affectées :
- Appels d'API (READ) : un appel par déploiement, quel que soit le nombre de fonctions
- Limite : 5 000 pour 100 secondes
- Appels d'API (ÉCRITURE) – 1 appel par fonction
- Limite: 80 pour 100 secondes
Consultez également la documentation de référence de la CLI Firebase.