Cette page décrit les métriques de latence fournies par Cloud Spanner. Si votre application présente une latence élevée, ces métriques peuvent vous aider à diagnostiquer et à résoudre le problème.
Vous pouvez afficher ces métriques dans la console Google Cloud et dans la console Cloud Monitoring. La page "Monitoring" de Google Cloud Console affiche deux métriques liées à la latence. La première concerne la latence, et la seconde la latence par type de transaction.
Latence
Les métriques de latence pour Spanner mesurent la durée nécessaire à Spanner pour traiter les fonctions de requête de lecture (Read, StreamingRead, ExecuteSql, StreamingExecuteSql, ExecuteBatchDml) ou d'écriture (Commit). Sélectionnez "Lecture/Écriture" pour afficher les métriques des deux. La métrique capture la durée réelle écoulée, et non la durée d'utilisation du processeur par Spanner.
Ces métriques de latence n'incluent pas la latence qui se produit en dehors de Spanner, telles que la latence du réseau et la latence au sein de votre couche d'application. Pour mesurer d'autres types de latence, vous pouvez utiliser Cloud Monitoring pour instrumenter votre application avec des métriques personnalisées.
Vous pouvez afficher les métriques de latence dans la console Google Cloud et dans la console Cloud Monitoring. Vous pouvez afficher des métriques de latence combinées qui incluent à la fois des fonctions de lecture et d'écriture, ou vous pouvez afficher des métriques distinctes pour les lectures et les écritures.
En fonction de la latence de chaque requête, Spanner regroupe les requêtes en centiles. Vous pouvez afficher les métriques de latence pour la latence du 50e centile et du 99e centile:
Latence du 50e centile : latence maximale, exprimée en secondes, pour les 50 % de requêtes les plus rapides. Par exemple, si la latence du 50e centile est de 0,5 seconde, Spanner a traité 50% des requêtes en moins de 0,5 seconde.
Cette métrique est parfois appelée latence médiane.
Latence du 99e centile : latence maximale, exprimée en secondes, pour les 99 % de requêtes les plus rapides. Par exemple, si la latence du 99e centile est de 2 secondes, Spanner a traité 99% des requêtes en moins de 2 secondes.
Latence et opérations par seconde
Lorsqu'une instance traite un petit nombre de requêtes au cours d'une période donnée, les latences des 50e et 99e centiles pendant cette période ne sont pas des indicateurs significatifs des performances globales de l'instance. Dans ces conditions, un nombre très faible d'anomalies peut modifier considérablement les métriques de latence.
Par exemple, supposons qu'une instance traite 100 requêtes pendant une heure. Dans ce cas, la latence du 99e centile de l'instance au cours de cette heure correspond au temps nécessaire au traitement de la requête la plus lente. Une métrique de latence basée sur une seule requête n'est pas représentative.
Latence par type de transaction
Les métriques de latence par type de transaction pour Spanner mesurent et indiquent le temps nécessaire à Spanner pour traiter une transaction. Vous pouvez afficher les métriques des transactions en lecture-écriture et en lecture seule. Le type de transaction "Lecture-écriture" inclut toutes les transactions en lecture-écriture, tandis que le type de transaction "Lecture seule" inclut toutes les transactions en lecture seule ainsi que les méthodes de lecture unique.
Tout comme les métriques de latence, ces graphiques regroupent les données en centiles. Vous pouvez afficher la métrique "Latence par type de transaction" pour les latences des 50e et 99e centiles.
Une différence majeure entre la métrique de latence et la métrique de latence par type de transaction est que le graphique Latence par type de transaction vous permet de ventiler le type de transaction en lecture seule par "Leader impliqué" ou "Aucune variante optimale impliquée". Si vous sélectionnez "Responsable impliqué", un graphique comprenant les requêtes impliquant le responsable est affiché. Par exemple, si une instance forte en lecture seule est demandée à partir d'une instance dupliquée en lecture seule, l'instance maître est consultée pour s'assurer que l'instance dupliquée en lecture seule dispose des données les plus récentes. Dans ce cas, sélectionner "Leader is impliqué" permet d'évaluer le temps total nécessaire au traitement d'une transaction de lecture forte. Si vous sélectionnez "Aucun leader impliqué", le graphique affiche les lectures pour lesquelles aucun leader n'a été impliqué. Par exemple, si une lecture non actualisée avec une limite d'horodatage définie sur au moins 15 secondes est demandée à partir d'une instance dupliquée en lecture seule, celle-ci peut diffuser la lecture non actualisée sans impliquer l'instance maître. En comparaison, les lectures impliquant le leader peuvent subir une latence plus élevée. Vous pouvez utiliser ces graphiques pour évaluer la différence de latence entre les lectures fortes et les lectures non actualisées. Notez que dans certains cas, une lecture non actualisée peut également être diffusée par un leader. Dans ce cas, les lectures non actualisées s'affichent sous le graphique "Leader impliqué".
Pour les transactions en lecture-écriture, la variante optimale est toujours impliquée dans la transaction. Par conséquent, les données affichées sur le graphique incluent toujours le temps nécessaire à la requête pour atteindre la variante optimale et recevoir une réponse.
Diagnostic des problèmes de latence
Dans les sections suivantes, nous allons voir comment diagnostiquer plusieurs problèmes courants susceptibles de générer une latence élevée de bout en bout sur votre application.
Pour consulter rapidement les métriques de latence d'une instance, utilisez la console Google Cloud. Pour examiner les métriques plus en détail et trouver des corrélations entre la latence et d'autres métriques, utilisez la console Cloud Monitoring.
Latence totale élevée, faible latence de Spanner
Si votre application subit une latence plus élevée que prévu, mais que les métriques de latence pour Spanner sont nettement inférieures à la latence totale de bout en bout, il se peut que le code de votre application présente un problème. Si votre application présente un problème de performances qui ralentit certains chemins de code, la latence totale de bout en bout peut augmenter pour chaque requête.
Pour détecter ce problème, analysez votre application afin d'identifier les chemins de code qui sont plus lents que prévu.
Vous pouvez également commenter le code qui communique avec Spanner, puis mesurer à nouveau la latence totale. Si la latence totale ne change pas beaucoup, il est peu probable que Spanner soit à l'origine de la latence élevée.
Latence totale élevée, latence Spanner élevée
Si votre application subit une latence plus élevée que prévu et que les métriques de latence de Spanner sont également élevées, plusieurs raisons sont possibles:
Votre instance nécessite davantage de capacité de calcul. Si votre instance ne dispose pas de suffisamment de ressources de processeur et que son utilisation dépasse le nombre maximal recommandé, il se peut que Spanner ne puisse pas traiter vos requêtes rapidement et efficacement.
Certaines de vos requêtes entraînent une utilisation élevée du processeur. Si vos requêtes ne tirent pas parti des fonctionnalités de Spanner qui améliorent l'efficacité, telles que les paramètres de requête et les index secondaires, ou si elles incluent un grand nombre de jointures ou d'autres opérations nécessitant une utilisation intensive des processeurs, elles peuvent utiliser une grande partie des ressources de processeur de votre instance.
Pour analyser ces problèmes, utilisez la console Cloud Monitoring afin de trouver une corrélation entre une utilisation intensive du processeur et une latence élevée. En outre, analysez les métriques de requête de votre instance afin d'identifier toute requête nécessitant une utilisation intensive du processeur au cours de la même période.
Si vous constatez que l'utilisation du processeur et la latence sont toutes les deux élevées, prenez les mesures nécessaires pour résoudre le problème :
Si vous avez trouvé peu de requêtes nécessitant une utilisation intensive du processeur, ajoutez de la capacité de calcul à l'instance.
L'ajout de la capacité de calcul fournit davantage de ressources de processeur et permet à Spanner de gérer une charge de travail plus importante.
Si vous avez trouvé des requêtes nécessitant une utilisation intensive des processeurs, consultez les plans d'exécution de requêtes pour comprendre pourquoi elles sont lentes, puis mettez à jour vos requêtes afin de suivre les bonnes pratiques SQL pour Spanner.
Vous devrez peut-être également examiner la conception du schéma de la base de données et mettre à jour le schéma afin de permettre l'optimisation des requêtes.
Étapes suivantes
- Surveillez votre instance avec la console Google Cloud ou la console Cloud Monitoring.
- Découvrez comment trouver des corrélations entre la latence élevée et d'autres métriques.
- Découvrez comment réduire la latence de lecture en suivant les bonnes pratiques SQL et en utilisant les limites d'horodatage.
- Apprenez-en plus sur les métriques de latence dans les tables de statistiques sur les requêtes, que vous pouvez récupérer à l'aide d'instructions SQL.
- Découvrez comment la configuration de l'instance affecte la latence.