Performance applicative et observabilité : quels indicateurs faut-il regarder ?

L’enjeu de l’observabilité pour la performance des applications

Depuis quelques années, les solutions de monitoring des applications ont évolué pour devenir des solutions d’observabilité, avec la promesse d’avoir une vision unifiée de la performance et du bon fonctionnement des applications. Malheureusement, comme souvent, ces solutions d’observabilité arrivent avec de très (trop) nombreux indicateurs qui, au lieu de faire avancer le débat, perdent les utilisateurs dans d’innombrables écrans de statistiques…

Dans cet article, on vous propose de faire le tour des différents indicateurs/écrans, et de vous partager ce qu’il nous parait pertinent de regarder !

Fuyez les indicateurs agrégés de performance

Je sais que c’est la mode et qu’on trouve ça beau dans un powerpoint, mais, le fameux super index agrégé qui est supposé vous donner une vision unifiée de la performance de vos applications, ne sert à rien. Oui, je sais que l’éditeur vous l’a vendu comme étant la super fonctionnalité boostée à l’IA, mais c’est le plus souvent inutile, et ce, pour 3 raisons principales :

• Un indicateur, quel qu’il soit, doit vous permettre de déclencher une action corrective si celui-ci varie. Or, avec un indicateur agrégé, vous ne savez pas quel est le défaut de performance…
• Comme tout indicateur agrégé, il va varier d’une manière pondérée en fonction des sous-indicateurs qu’il utilise, et il se peut que deux variations opposées s’annulent et vous donne l’impression que tout marche bien… alors que non !
• La formule de calcul est souvent un mystère, et mal comprise de tous.

Généralement, il faut bien se l’avouer, au début, on trouve ça super ! Puis, un beau jour, notre client pour lequel nous avons développé une application, nous dit que cette dernière est lente, et nous, on regarde bêtement notre indicateur sans pour autant comprendre ce qu’il se passe… C’est à partir de ce moment-là qu’on commence à s’interroger et à remettre en question ce qu’on a mis en place !

L’informatique, c’est finalement plus facile qu’on ne le pense :) Si les performances sont lentes, c’est que quelque chose est lent ! Il faut regarder quoi, et pour ça, concentrons-nous sur ce qui a réellement de la valeur dans ces outils.

Quels indicateurs regarder dans sa plateforme d’observabilité ?

Il faut regarder des indicateurs que je vais nommer comme “purs” ! Je veux dire par là, des indicateurs qui sont objectivement la mesure de quelque chose de compréhensible et de quantifiable pour un être humain !

Le temps de réponse des services REST

Le temps de réponse mesuré en ms (ou seconde, si jamais c’est trop lent), est une mesure fiable qui permet de mesurer le temps mis par un service pour répondre à une demande. Le plus généralement, ce temps est mesuré depuis l’entrée du serveur jusqu’à la sortie de la réponse de votre service. Cette mesure est parfaitement compréhensible : si votre service met 1 seconde pour répondre, alors, de l’autre côté, devant son navigateur, la personne attend 1 seconde. C’est aussi simple que ça !

Je préviens tout de suite, NE REGARDEZ PAS LES MOYENNES ! Pourquoi ? Parce que les moyennes sont calculées sur des échantillons larges de données et ne reflètent pas le détail de ce qu’il se passe. Si vous moyennez le temps de réponse d’une méthode d’ajout au panier avec le temps de réponse de vos notifications, vous allez obtenir une moyenne basse, alors que, l’ajout au panier est peut-être très long, et le temps de vos notifications est lui peut-être très court. Et comme vous faites plus de notifications que d’ajouts au panier, alors votre analyse de la moyenne ne veut rien dire sur la performance de votre application !

Donc, on se concentre sur le temps de réponse unitaire de chaque méthode de votre application. Et dans la vraie vie, il n’y en a pas toujours 300 milles ! La bonne approche est de regarder les appels les plus longs et de commencer à traiter ceux-là. Pourquoi se focaliser sur les plus longs ? Parce qu’au-delà d’avoir un impact négatif sur le ressenti utilisateur (oui, il suffit d’une page longue pour que le ressenti de l’application soit mauvais, même si toutes les autres fonctionnalités vont vite), les services longs impactent négativement le reste du serveur. Comme le serveur perd plusieurs secondes à traiter un appel, il n’en traite pas d’autres ! Et un mauvais service peut ralentir toutes les autres fonctionnalités de votre application.

Donc on se concentre sur les plus lents d’abord, et on commence par raisonner à haute voix. Le temps de traitement d’une requête dans l’absolu ne veut rien dire. Dire qu’un appel RESTREST (REpresentational State Transfer) est un style d'architecture logicielle qui fonctionne sous un certain nombre de contraintes. met 300 millisecondes, est-ce que c’est bien ou pas ? Est-ce cohérent ? Dois-je espérer mieux de mon équipe de développement ? Tout dépend de ce que fait l’appel REST !

Néanmoins, voici quelques repères :

• Faire un appel REST à vide sur un serveur dans le Cloud met environ 20 ms. (ordre de grandeur)

Le reste, c’est donc votre traitement qui le prend ! Cela veut dire que la barrière d’optimisation est là. Mais si votre service prend 3 secondes, ce n’est pas l’hébergeur le problème, mais votre code ! Je conseille toujours de faire un appel à vide pour avoir ce temps de référence de votre service d’hébergement.

A titre personnel, je considère que 100 ms est une bonne barre de référence pour se dire que tout ce qu’il y a en dessous, c’est correct ! Dans un premier temps, je vais donc me concentrer plutôt sur ce qu’il se passe au-dessus des 100 ms.

Le reste, c’est la base de données mon ami (ou un service externe)

Une fois que vous avez identifié le ou les services qui sont les plus lents, alors on rentre dans le détail. Pour le coup, la plateforme d’observabilité ne va pas trop vous servir dans cette étape… il faut revenir à ce que fait le code !

Que fait le code justement dans un service ?

• Désérialisation de la requête
• Traitement et calcul
• Requêtes en base de données
• Traitement et calcul
• Sauvegarde en base
• Sérialisation du retour

Dans la majorité des cas, ce n’est pas plus compliqué que ça. Si vous utilisez un framework, il est rare que le code fasse n’importe quoi, vous êtes normalement bien structuré. On s’aperçoit vite que le bottleneck est l’accès à la base de données, et en particulier, les requêtes SQL.

Je mets volontairement de côté l’appel à un service externe type AWSLe Cloud AWS (Amazon WebServices) est une plateforme de services cloud développée par le géant américain Amazon., car, même si ça peut être le cas, dans la majorité des applications et des services, c’est plus simple que ça !

Donc, il faut se concentrer sur ce que fait le service et les requêtes qui sont générées. A ce moment là, il ne sert plus à rien de raisonner de manière ensembliste. Ce qui compte, c’est le traitement unitaire du service. Si vous optimisez unitairement le service, alors, il ira plus vite de manière ensembliste aussi. Et en plus, vous gagnerez de la bande passante dans votre hébergement pour traiter d’autres requêtes REST et SQLLangage permettant de communiquer avec une base de données..

Les bons tableaux de bord d’observabilité pour les performances

Vous l’aurez donc compris, dans cet article un peu parti pris, les 2 indicateurs pour la performance qui sont les plus importants sont d’un côté, le temps de traitement des services REST (en évitant les moyennes !) et de l’autre, les requêtes SQL. Si vous construisez ces deux dashboards, vous aurez une vision opérationnelle pour travailler à l’amélioration des performances de votre application.

Dashboard 1 - Temps de traitement des services REST (en ms)

Dans ce dashboard, on vient mettre les temps de traitement des méthodes REST, classées par temps de réponse DESC. Puis, on se concentre semaine après semaine pour essayer de les améliorer.

Dashboard 2 - Temps de traitement des requêtes SQL

Dans ce dashboard, on vient mettre toutes les requêtes SQL, avec, si possible, le temps de traitement cumulé par le serveur de BDD. Cela permet de voir si une requête, même unitairement simple et rapide, est appelée trop de fois et nécessite néanmoins une optimisation.

Une fois ces deux indicateurs / dashboards maitrisés, on peut se pencher sur les autres indicateurs de performances. Mais par pitié, ne perdez pas des heures à regarder le temps de transaction/s, d’accès disque, de moyenne de CPU… ces indicateurs ne vous apprendront rien la plupart du temps rien ! KEEP IT SIMPLE.