Résoudre les problèmes de latence

Cette page explique comment résoudre les problèmes de latence avec Firestore.

Latence

Le tableau suivant décrit les causes possibles d'une augmentation de la latence:

Cause de la latence Types d'opérations concernés Solution
Trafic soutenu dépassant la règle 500-50-5 lecture, écriture (read, write)

Pour augmenter le trafic rapidement, Firestore tente d'effectuer un scaling automatique afin de répondre à l'accroissement de la demande. Lorsque Firestore effectue un scaling, la latence diminue.

Les hotspots (taux de lecture, d'écriture et de suppression élevés pour une plage de documents restreinte) limitent la capacité de scaling de Firestore. Consultez la page Concevoir des solutions évolutives et identifiez les hotspots dans votre application.

Contention imputable à la mise à jour trop fréquente d'un seul document ou à des transactions lecture, écriture (read, write)

Réduisez le taux d'écriture sur des documents individuels.

Examinez la contention des données dans les transactions et l'utilisation des transactions.

Requêtes de jointure par fusion lentes lecture (read) Par exemple, les requêtes comportant plusieurs filtres d'égalité (==) mais ne s'appuyant pas sur des index composites peuvent ralentir les requêtes de jointure par fusion. Pour améliorer les performances, ajoutez des index composites pour ces requêtes. Reportez-vous à la raison°3 dans la section Pourquoi ma requête Firestore est-elle lente ?
Lectures volumineuses renvoyant de nombreux documents lecture (read) Utilisez la pagination pour scinder les opérations de lecture de grande taille.
Trop de suppressions récentes read
Cela a un impact considérable sur les opérations qui répertorient les collections d'une base de données.		 Si la latence est causée par un nombre trop élevé de suppressions récentes, le problème devrait se résoudre automatiquement après un certain temps. Si le problème persiste, contactez l'assistance.
Ajouts et suppressions d'écouteurs trop rapides requêtes d'écoute en temps réel Consultez les bonnes pratiques pour les mises à jour en temps réel.
Écoute de documents volumineux ou d'une requête avec de nombreux résultats requêtes d'écoute en temps réel Consultez les bonnes pratiques pour les mises à jour en temps réel.
Distribution ramifiée d'index, en particulier pour les champs de tableau et les champs de mappage écriture (write) Vérifiez l'utilisation des champs de tableau et de carte. Pour les champs de mappage, vous pouvez désactiver l'indexation des sous-champs. Vous pouvez également utiliser des exceptions au niveau de la collection.
Écritures volumineuses et écritures par lot écriture (write)

Essayez de réduire le nombre d'écritures dans chaque tâche d'écriture par lot. Les écritures par lot sont atomiques et la présence de nombreuses écritures dans un seul lot peut entraîner une augmentation de la latence et des conflits. Par exemple, un lot de 10 écritures est plus performant qu'un lot de 500 écritures.

Pour la saisie de données groupées ne nécessitant pas d'atomicité, utilisez une bibliothèque cliente de serveur avec des écritures individuelles chargées en parallèle. Les écritures par lot sont plus performantes que les écritures sérialisées, mais pas plus que les écritures chargées en parallèle.