Cette page détaille les limites évolutives et basées sur l'utilisation pour les fonctions Cloud selon le plan tarifaire Blaze avec paiement à l'utilisation. Ces limites s'appliquent aux projets Firebase qui déploient des fonctions dans l'environnement d'exécution Node.js 10.
Le plan Blaze fournit gratuitement une quantité généreuse d’appels, de temps de calcul et de trafic Internet. Cependant, les déploiements de fonctions entraînent des frais minimes pour l'espace de stockage utilisé pour le conteneur de la fonction. Consultez la FAQ Firebase pour plus d'informations.
Les quotas pour Google Cloud Functions englobent trois domaines :
Limites des ressources
Ceux-ci affectent la quantité totale de ressources que vos fonctions peuvent consommer.
Délais
Ceux-ci affectent la durée pendant laquelle les choses peuvent durer.
Limites de taux
Ceux-ci affectent 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 des Cloud Functions (1re génération) et des Cloud Functions (2e génération) sont notées le cas échéant.
Limites des ressources
Les limites de ressources affectent la quantité totale de ressources que vos fonctions peuvent consommer. La portée régionale est par projet, et chaque projet maintient ses propres limites.
| Quota | Description | Limite (1re génération) | Limite (2e génération) | Peut être augmenté | Portée |
|---|---|---|---|---|---|
| Nombre de fonctions | Le 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 du déploiement | La taille maximale d'un déploiement de fonction unique | 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 invocation |
| Taille maximale de la réponse HTTP non compressée | Données envoyées depuis les 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 invocation |
| Taille maximale des événements pour les fonctions basées sur les événements | Données envoyées lors d'événements aux fonctions d'arrière-plan | 10 Mo | 512 Ko pour les événements Eventarc. 10 Mo pour les événements existants. | Non | par événement |
| Mémoire de fonction maximale | Quantité de mémoire que chaque instance de fonction peut utiliser | 8 Go | 16 Go | Non | par fonction |
Délais
| Quota | Description | Limite (1re génération) | Limite (2e génération) | Peut être augmenté | Portée |
|---|---|---|---|---|---|
| Durée maximale de la fonction | La durée maximale pendant laquelle une fonction peut s'exécuter avant d'être terminée de force | 540 secondes | 60 minutes pour les fonctions HTTP. 10 minutes pour les fonctions événementielles. | Non | par invocation |
Limites de taux
| Quota | Description | Limite (1re génération) | Limite (2e génération) | Peut être augmenté | Portée |
|---|---|---|---|---|---|
| Appels API (LIRE) | Appels pour décrire ou répertorier des fonctions via l'API Cloud Functions | 5 000 par 100 secondes | 1200 toutes les 60 secondes | Uniquement pour la 1ère génération | par projet (1ère génération) par région (2e génération) |
| Appels API (ÉCRITURE) | Appels pour déployer ou supprimer des fonctions via l'API Cloud Functions | 80 toutes les 100 secondes | 60 toutes les 60 secondes | Non 1 | par projet (1ère génération) par région (2e génération) |
| Appels API (CALL) | Appels à l'API "call" | 16 toutes les 100 secondes | N / A | Non 2 | par projet |
Évolutivité
Les fonctions Cloud invoquées par HTTP évoluent rapidement pour gérer le trafic entrant, tandis que les fonctions d'arrière-plan évoluent plus progressivement. La capacité d'une fonction à évoluer est dictée par quelques facteurs, notamment :
- Le temps nécessaire à l'exécution d'une fonction (les fonctions à exécution courte peuvent généralement évoluer pour gérer davantage de requêtes simultanées).
- Le temps nécessaire à une fonction pour s'initialiser lors d'un démarrage à froid .
- Le taux d'erreur de votre fonction.
Facteurs transitoires, 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 | Peut être augmenté | Portée | Version de produit |
|---|---|---|---|---|---|
| Nombre maximal d'appels simultanés | Le nombre maximal d'appels simultanés d'une seule fonction Exemple : si le traitement de chaque événement prend 100 secondes, le taux d'invocation sera limité à 30 par seconde en moyenne | 3 000 | Oui | par fonction | 1ère génération uniquement |
| Taux d'appel maximum | Le taux maximum d'événements gérés par une seule fonction Exemple : si le traitement d'un événement prend 100 ms, le taux d'invocation sera limité à 1000 par seconde même si seulement 100 requêtes, en moyenne, sont traitées en parallèle | 1000 par seconde | Non | par fonction | 1ère génération uniquement |
| Taille maximale des données d'événements simultanés | La taille totale maximale des événements entrants pour les appels simultanés d'une seule fonction Exemple : si les événements ont une taille de 1 Mo et que leur traitement prend 10 secondes, le débit moyen sera de 1 événement par seconde, car le 11ème événement ne sera traité qu'une fois le traitement de l'un des 10 premiers événements terminé. | 10 Mo | Non | par fonction | 1ère génération et 2ème génération |
| Débit maximum des événements entrants | Le débit maximum des événements entrants vers une seule fonction Exemple : si les événements ont une taille de 1 Mo, le taux d'invocation peut être maximum de 10 par seconde, même si les fonctions se terminent dans les 100 ms. | 10 Mo par seconde | Non | par fonction | 1ère génération et 2ème génération |
Lorsque vous atteignez une limite de quota
Lorsqu'une fonction consomme la totalité d'une ressource allouée, la ressource devient indisponible jusqu'à ce que le quota soit actualisé ou augmenté. Cela peut signifier que votre fonction et toutes les autres fonctions du même projet ne fonctionneront pas d'ici là. Une fonction renvoie un code d'erreur HTTP 500 lorsqu'une des ressources dépasse son quota et que la fonction ne peut pas s'exécuter.
Pour augmenter les quotas au-dessus des valeurs par défaut répertoriées ici, accédez à la page Quotas de Cloud Functions , sélectionnez les quotas que vous souhaitez modifier, cliquez sur MODIFIER LES QUOTAS , fournissez vos informations utilisateur si vous y êtes invité et saisissez la nouvelle limite de quota pour chaque quota que vous avez sélectionné.
Limites de quota pour le déploiement de Firebase CLI
Pour chaque fonction déployée par la CLI Firebase, ces types de débit et de limites de temps sont affectés :
- Appels API (READ) - 1 appel par déploiement, quel que soit le nombre de fonctions
- Limite : 5 000 toutes les 100 secondes
- Appels API (WRITE) - 1 appel par fonction
- Limite : 80 toutes les 100 secondes
Voir également la référence Firebase CLI .