L'optimisation des performances commence par l'identification des métriques clés, généralement liées à la latence et au débit. L'ajout d'une surveillance pour capturer et suivre ces métriques expose les points faibles de l'application. Les métriques permettent d'optimiser les métriques de performances.
De plus, de nombreux outils de surveillance vous permettent de configurer des alertes pour vos métriques, afin d'être averti lorsqu'un certain seuil est atteint. Par exemple, vous pouvez configurer une alerte pour être averti lorsque le pourcentage de requêtes ayant échoué augmente de plus de X% par rapport aux niveaux normaux. Les outils de surveillance peuvent vous aider à identifier les performances normales et à détecter les pics inhabituels de latence, de quantité d'erreurs et d'autres métriques clés. La possibilité de surveiller ces métriques est particulièrement importante pendant les périodes critiques pour l'entreprise ou après l'envoi d'un nouveau code en production.
Identifier les métriques de latence
Assurez-vous que votre UI est aussi réactive que possible, en gardant à l'esprit que les utilisateurs attendent des applications mobiles des performances encore plus élevées. La latence doit également être mesurée et suivie pour les services de backend, d'autant plus qu'elle peut entraîner des problèmes de débit si elle n'est pas contrôlée.
Voici quelques exemples de métriques à suivre :
- Durée de la requête
- Durée de la requête au niveau de précision du sous-système (par exemple, les appels d'API)
- Durée du job
Identifier les métriques de débit
Le débit est une mesure du nombre total de requêtes diffusées sur une période donnée. Le débit peut être affecté par la latence des sous-systèmes. Vous devrez peut-être optimiser la latence pour améliorer le débit.
Voici quelques suggestions de métriques à suivre :
- Requêtes par seconde
- Taille des données transférées par seconde
- Nombre d'opérations d'E/S par seconde
- Utilisation des ressources, comme l'utilisation du processeur ou de la mémoire
- Taille du backlog de traitement, comme Pub/Sub ou le nombre de threads
Pas seulement la moyenne
Une erreur courante lors de la mesure des performances consiste à ne s'intéresser qu'au cas moyen. Bien que cela soit utile, cela ne fournit pas d'informations sur la distribution de la latence. Il est préférable de suivre les centiles de performances, par exemple les 50e, 75e, 90e et 99e centiles d'une métrique.
En général, l'optimisation peut être effectuée en deux étapes. Tout d'abord, optimisez la latence du 90e centile. Ensuite, considérez le 99e centile, également appelé latence de queue : la petite partie des requêtes qui prennent beaucoup plus de temps à s'exécuter.
Surveillance côté serveur pour des résultats détaillés
Le profilage côté serveur est généralement préférable pour le suivi des métriques. Le côté serveur est généralement beaucoup plus facile à instrumenter, permet d'accéder à des données plus précises et est moins sujet aux perturbations dues aux problèmes de connectivité.
Surveillance du navigateur pour une visibilité de bout en bout
Si votre intégration de l'API Google Ads fournit une interface Web aux utilisateurs finaux, le profilage du navigateur peut fournir des insights supplémentaires sur l'expérience utilisateur. Il peut indiquer les pages qui ont des requêtes lentes, que vous pouvez ensuite mettre en corrélation avec la surveillance côté serveur pour une analyse plus approfondie.
Google Analytics fournit également une surveillance prête à l'emploi des temps de chargement des pages dans le rapport sur les temps de chargement des pages Analytics. Cela fournit plusieurs vues utiles pour comprendre l'expérience utilisateur sur votre site, en particulier :
- Temps de chargement des pages
- Temps de chargement des redirections
- Temps de réponse du serveur
Surveillance dans le cloud
De nombreux outils vous permettent de capturer et de surveiller les métriques de performances de votre application. Par exemple, vous pouvez utiliser Google Cloud Logging pour consigner les métriques de performances dans votre projet Google Cloud, puis configurer des tableaux de bord dans Google Cloud Monitoring pour surveiller et segmenter les métriques consignées.
Consultez le guide de journalisation pour obtenir un exemple d'intercepteur de journalisation gRPC personnalisé écrit pour la bibliothèque cliente Python. Dans cet exemple, l'intercepteur appelle logger.log_struct() pour envoyer un dictionnaire Python de données de journal structurées à Cloud Logging, que Cloud Logging stocke dans le champ jsonPayload de l'entrée de journal :
logger.log_struct({
"method": method_name,
"elapsed_ms": elapsed_milliseconds,
"is_fault": is_fault,
})
Une fois ces données disponibles dans Google Cloud, vous pouvez créer des métriques à partir des données consignées pour gagner en visibilité sur votre application via Google Cloud Monitoring. Suivez le guide sur les métriques basées sur les journaux définies par l'utilisateur pour créer des métriques à l'aide des journaux envoyés à Google Cloud Logging.
Vous pouvez également utiliser les bibliothèques clientes Cloud Monitoring pour définir des métriques dans votre code et les envoyer directement à Monitoring, indépendamment des journaux.
Exemple de métrique basée sur les journaux
Supposons que vous souhaitiez surveiller la valeur is_fault pour mieux comprendre les taux d'erreur dans votre application. Étant donné que logger.log_struct() écrit des champs de dictionnaire structurés sous jsonPayload dans chaque entrée de journal Cloud Logging, vous pouvez créer une métrique de compteur nommée ErrorCount avec un filtre correspondant aux requêtes ayant échoué, par exemple jsonPayload.is_fault = true.
Dans Cloud Logging, les libellés vous permettent de regrouper vos métriques en catégories en fonction d'autres données des journaux. Vous pouvez configurer un libellé STRING nommé Method dans le champ jsonPayload.method envoyé à Cloud Logging pour ventiler le nombre d'erreurs par méthode de l'API Google Ads.
Une fois la métrique ErrorCount et l'étiquette Method configurées, vous pouvez créer un graphique dans Cloud Monitoring pour surveiller ErrorCount, avec Method comme critère de regroupement.
Alertes
Dans Cloud Monitoring et d'autres outils, vous pouvez configurer des règles d'alerte qui spécifient quand et comment les alertes doivent être déclenchées par vos métriques. Pour savoir comment configurer des alertes Cloud Monitoring, suivez le guide sur les alertes basées sur les métriques de journaux.