Optimisation des performances de l’application avec le profil continu de la forme de données

Introduction

Les applications modernes se comportent très différemment dans la production par rapport aux environnements de développement ou de test. Les demandes et les comptes des valeurs aberrantes, les cas de bord, les modifications de configuration, les fonctionnalités de sécurité et les pointes de demande peuvent faire comporter une application de manière inattendue. Cela peut conduire à une mauvaise performance du processeur et de la mémoire, ce qui peut être coûteux et entraîner une expérience de l’utilisateur final indésirable. Datadog Continuous Profiler vous permet de découvrir rapidement des bogues coûteux et d’identifier les améliorations de code pour vous aider à réduire les coûts d’infrastructure et à améliorer l’expérience de l’utilisateur final.

Objectif

À la fin de ce blog, vous pourrez faire ce qui suit:

• Déterminez quand et comment utiliser le profilage continu pour diagnostiquer les problèmes de performances de l’application.
• Appliquez une méthodologie de diagnostic de performance pour résoudre les problèmes de performances du code à l’aide des types de profil, du profilage des points de terminaison et de la comparaison des profils dans Continuous Profiler.

Profilage de code continu

1. Le profilage de code continu vous permet de mesurer les performances du code à tout moment dans n’importe quel environnement.
2. En production, un processus d’application est principalement une boîte fermée. Vous pouvez observer les comportements externes mais pas les internes. Le profilage est un moyen de regarder à l’intérieur de la case, d’observer ces comportements internes et de mesurer les performances du code de l’application. Vous pouvez détecter et optimiser les lignes de code les plus longues et les plus à forte intensité de ressources qui affectent les coûts et l’expérience de l’utilisateur final.
3. Le profilage devient beaucoup plus efficace lorsqu’il est effectué dans la production, car il est généralement difficile et qui prend du temps de simuler le comportement de production ou de reproduire des goulots d’étranglement spécifiques et des pannes dans les environnements de non-production.

Profil continu dans le réseau de données

Exemple d’un graphique de flamme du profileur de temps CPU dans le profileur continu.

Datadog Continuous Profiler est un profileur de code de production toujours activé qui vous permet d’analyser les performances au niveau du code dans l’ensemble de votre environnement, avec un minimum de frais généraux. Les profils révèlent quelles méthodes / fonctions consomment le plus de ressources, telles que le CPU, l’allocation de la mémoire, le temps du mur et le temps d’E / S passé. Avec ces informations, vous pouvez optimiser votre code pour réduire les coûts de latence des utilisateurs finaux et des fournisseurs de cloud.

Le profilage continu dans Datadog vous permet de faire ce qui suit:

• Effectuer un traçage au niveau du code avec une instrumentation nulle
• Visualisez toutes vos traces de pile en un seul endroit
• Découvrez les goulots d’étranglement dans votre code en un coup d’œil
• Filtre les données de profil à l’aide de balises
• Obtenez des informations exploitables pour les améliorations des performances

Le profilage continu va au-delà du traçage distribué

Considérez que vous avez un service appelé Films-API-Java qui a plusieurs points de terminaison qui renvoient les métadonnées de film stockées dans une base de données. Vous apprenez que le service ne fonctionne pas bien et que les utilisateurs connaissent des problèmes accrus de latence. Vous souhaitez optimiser les performances du service pour vous assurer que les utilisateurs ont la meilleure expérience.

Vous commencez à utiliser DataDog APM et le traçage distribué pour étudier les problèmes de performances. Par exemple, si vous voyez des portées supplémentaires en traces pour des appels répétés inutiles vers une base de données lorsque les demandes sont faites sur un point de terminaison, vous savez que vous pouvez utiliser ces informations pour déterminer un correctif. Cependant, pour certains problèmes, vous voyez que vous devez aller au-delà du traçage distribué pour pouvoir diagnostiquer les problèmes et optimiser les performances. Dans l’exemple ci-dessous, la trace montre qu’il faut plus de 2 secondes pour répondre à une demande, mais il n’y a pas de plans d’enfants ou d’autres indicateurs qui peuvent vous en dire plus sur ce qui pourrait provoquer la lenteur des performances.

Exemple d’une trace de latence élevée sans portée.

Pour les problèmes que vous ne pouvez pas résoudre en utilisant APM, vous pouvez utiliser un profileur continu pour étudier à un niveau plus granulaire. La différence entre le traçage distribué et le profilage continu est que les traces vous indiquent quelles demandes étaient lentes au niveau du service, tandis que les profils vous indiquent pourquoi ils étaient lents au niveau du code.

Profils

Dans Datadog, les données de trace et les données de profilage sont automatiquement liées pour les processus d’application qui ont à la fois APM et le profileur continu activé. Dans le panneau de détails de trace dans APM, vous pouvez vous déplacer directement à partir des informations pour une trace ou une portée sélectionnée dans une trace aux données de profilage associées à l’aide de l’onglet Profils.

L’interface utilisateur des profils trouvée dans le panneau de détails pour une trace.

Interprétation du graphique de flamme du profileur

Semblable aux traces, les profils sont représentés dans des graphiques de flamme. Cependant, les graphiques de flamme profiler sont interprétés différemment parce que les données qu’ils représentent sont différentes. Le graphique de flamme de profileur illustré ci-dessous représente le temps CPU par méthode.

Profiler Flame Graph avec des détails importants expliqués.

• L’axe des x représente la consommation totale du processeur.
• Chaque barre horizontale est un cadre.
• Chaque trame représente une méthode. Les cadres sont disposés de haut en bas, dans l’ordre où chaque méthode a été appelée lors de l’exécution d’un programme.
• Chaque couleur représente un ensemble différent.
• Le cadre supérieur défini ici est généralement appelé «cadre racine» et sa valeur est la somme des cadres enfants. En le comparant à un graphique à tarte, le cadre racine est la tarte totale et chaque trace de pile représente une pièce différente de la tarte.
• La largeur de chaque trame correspond à sa consommation de ressources. Plus le cadre est long, plus il y a de temps CPU.
• Deux méthodes apparaissant côte à côte auraient pu être appelées en parallèle ou dans n’importe quel ordre. Les cadres sont commandés par ordre alphabétique de gauche à droite.
• Le cadre inférieur est appelé le cadre des feuilles et représente la dernière méthode appelée dans la pile. Le cadre des feuilles ne représente que son temps de soi car il n’a pas de cadres enfants.

Décomposer la consommation de ressources à l’aide de types de profil

Il existe une variété de types de profils que vous pouvez voir dans Continuous Profiler pour vous aider à comprendre et à étudier différents aspects des performances de votre code.

Exemple de types de profils disponibles en fonction des données de profil filtrées.

Comprendre les types de profil et la consommation de ressources

Chaque type de profil représente un type de consommation de ressources, tel que le processeur, le temps mural ou la mémoire. Les types de profils disponibles pour vous à sélectionner peuvent différer en fonction du profilage de la langue. Voici les types de profils les plus courants:

• Processeur Mesures de profilage quelles méthodes consomment le plus de processeur d’une application.
• Allocation Le profilage mesure la quantité de mémoire allouée par une méthode donnée.
• Tas Le profilage mesure la quantité de mémoire de tas allouée par chaque fonction qui n’a pas été collectée à la poubelle. Ceci est utile pour étudier l’utilisation globale de la mémoire de votre service et identifier les fuites potentielles de mémoire.
• Verrouillage Le profilage mesure le temps qu’un fil attend d’acquérir une serrure et ne fait donc rien.
• Heure du mur Le profilage mesure le temps effectif passé par les méthodes. Il peut être utile de déboguer la latence à première vue, puis de creuser dans les autres types de profilage pour savoir ce qui provoquait la latence. Le profil de temps mural peut être considéré comme le plus similaire au graphique de flamme APM associé.
• Fichier des E / S et des E / S de socket Mesurez le nombre de temps passés par des méthodes sur le disque.
• Exceptions Mesurez la quantité d’exceptions lancées. Le profileur ne capte pas / ne gère pas les exceptions, mais il suit leur création.

Enquêter sur des points de terminaison lents avec le profilage des points finaux

Le profilage des points de terminaison vous permet de mettre en place des graphiques de flamme de profileur par n’importe quel point de terminaison API d’un service, vous pouvez donc trouver des points de terminaison qui sont lents et provoquant une mauvaise expérience de l’utilisateur final. Le débogage et la compréhension de la raison pour laquelle un point final a une latence élevée peut être délicat. Par exemple, une latence élevée pourrait être causée par une méthode qui est lourde du processeur et sans le savoir sur le chemin critique d’un processus de demande où la latence est importante.

Vous pouvez effectuer ce qui suit avec le profilage des points de terminaison:

• Identifiez les méthodes d’étranglement qui ralentissent le temps de réponse global du point final.
• Isoler les points de terminaison supérieurs qui sont responsables de la consommation de ressources comme le processeur et la mémoire. Cela est particulièrement utile lorsque vous essayez d’optimiser votre service pour des gains de performances.
• Comprenez si le code tiers ou les bibliothèques d’exécution sont la raison pour laquelle les points de terminaison sont lents ou lourds sur la consommation de ressources.

Exemple de liste des points de terminaison qui apparaît dans la liste de résumé d’un profil.

En général, il est utile de suivre les terminaux consomment les ressources les plus précieuses, telles que le processeur et la mémoire. La liste peut vous aider à identifier si vos points de terminaison ont régressé ou si vous avez des points de terminaison nouvellement introduits qui consomment radicalement plus de ressources que prévu et ralentissent votre service global.

Comparaison des profils pour mieux comprendre les performances du code

La fonction Compare vous permet de comparer deux profils ou des agrégations de profil. Cela peut vous aider à identifier les améliorations, les régressions et les modifications structurelles des performances du code pendant que vous résolvez les problèmes. Par exemple, vous pouvez voir si le service que vous profitez prend plus ou moins de temps, en utilisant plus ou moins de mémoire, en faisant plus ou moins d’allocations, en train de lancer plus ou moins d’exceptions, ou y compris plus ou moins de code et d’appels que par le passé.

Capture d’écran de la comparaison entre deux graphiques de flamme de profileur.

Conclusion

Continuous Profiler est un outil puissant qui vous permet de profiler en continu votre code de production afin que vous puissiez étudier et optimiser ses performances. Vous pouvez découvrir et optimiser les parties inefficaces de votre code pour améliorer la consommation de ressources, les économies de coûts, les performances de l’application et l’expérience de l’utilisateur final.

Vous pouvez maintenant faire ce qui suit:

• Déterminez quand et comment utiliser le profilage continu pour diagnostiquer les problèmes de performance de l’application.
• Appliquez une méthodologie de diagnostic de performance pour résoudre les problèmes de performances du code à l’aide des types de profil, du profilage des points de terminaison et de la comparaison des profils dans le profileur continu.

Vous avez trouvé cela utile? PARTAGEZ-LE