Et maintenant, Roné, tu vas nous parler de...
Je ne sais pas comment faire la transition, mais en tout cas, il y a le feu là-dedans.
Oui, en fait, c'était un peu difficile de trouver des news, moi aussi,
mais j'ai lu un article que j'ai trouvé très intéressant.
Alors, en faisant ma veille un petit peu sur Rust, etc.
Mais je pense que ce que je vais dire n'est pas lié spécialement à Rust,
ça existe dans les autres langages.
Et en fait, c'est en gros un cas d'optimisation de performance pour un SAS.
Mais ce que j'ai trouvé intéressant, c'est que j'ai trouvé le sujet et la manière dont c'était abordé.
Accessible, c'est-à-dire que le problème est relativement facile à comprendre.
Et ça montre aussi l'utilisation d'outils, donc des fameux outils comme Flamegraph.
Donc, c'est plutôt que ces outils existent dans plusieurs langages
et qui permettent de déterminer où par exemple un programme prend le plus de temps.
Et puis un autre outil qui est dans l'article est Divan, qui permet de mettre en place des benchmarks.
Mais voilà, il y a plein d'outils pour faire ça dans les différents langages.
Et ce qui est intéressant, je pense, dans l'article, c'est de voir la démarche.
Donc ça part d'un SAS, qui est relativement lent, parce qu'il y a une opération qui est faite.
Donc c'est une entreprise qui travaille dans le domaine de la cartographie.
Et il découvre qu'il y a un filtre qui calcule 6 points dans ce qu'ils appellent un corridor.
Donc, en gros, l'idée, c'est que si on pour essayer d'expliquer très simplement,
l'idée, c'est qu'entre deux points, c'est comme si on mettait un gros coup de stabilo.
Et on cherche à savoir quels sont les points qui sont dans le trait du stabilo.
Et voilà, c'est pour imaginer un peu le truc.
Et il se trouve que ce filtre est très, très lent.
Et on passe un petit peu par toutes les étapes pour trouver le pourquoi du comment
et comment est trouvé la méthode pour grandement optimiser les performances
avec un petit peu aussi toutes les perturbations, enfin, les mauvaises influences
ou les mauvais feelings qu'on peut avoir par rapport à ce genre de cas.
Parce que souvent, et c'est ce qui est expliqué dans l'article, le gain, un tweet,
en se disant que ça doit être ça qui est lent.
Et en fait, la mesure avec le fait de mesurer, de faire un flame graph, etc.
et de suivre la démarche, et bien, il se rend compte qu'il part pas sur la bonne piste.
Et donc, est-ce qu'il y ait quand même quelque chose qui arrive assez souvent.
Et donc, voilà, cet article est passionnant et j'encourage tout le monde
qui peut avoir ce type de problématique à le lire, parce que c'est, je trouve,
une bonne source et quelque chose de... voilà, c'est...
une fois, c'est facile à comprendre et à matérialiser.
Voilà, j'imagine que vous n'avez pas forcément vu cet article, mais voilà,
est-ce que j'ai réussi à créer un petit peu de teasing pour... pour... pour que vous alliez y jeter un oeil, Nicolas.
Oui, alors moi, je connais les flame graphs depuis un bon moment.
Je les ai assez rarement utilisés, parce que ça demande quand même de mettre en place pas mal d'outillages.
Et j'ai deux choses à dire dessus. Le premier truc, c'est que c'est très marrant le...
l'outil pour visualiser les flame graphs. C'est un outil qui a été écrit par Brenn Dad Greg.
Donc, j'en avais déjà parlé de Brenn Dad Greg, qui a fait un super bouquin sur...
enfin, même plusieurs, sur les performances principalement sous les Unix.
Il y en a un sous Linux et il y en a un sur les autres.
Je ne sais plus exactement lesquels, mais bon, peu importe.
C'est une excellente ressource.
Regardez ce que fait cet homme-là, parce qu'il fait un travail fabuleux sur comment trouver les problèmes de perf.
C'est à ce... lors de l'épisode où on avait parlé des problèmes en production,
que j'en avais parlé avec notamment la méthodeuse.
Et le... l'outil flame graph, c'est un outil qui en parle.
Donc, c'est assez marrant de voir que ça existe toujours.
Et le deuxième truc que je voulais dire, c'est le fait d'avoir ces outils à disposition en prod.
Moi, je vous conseille de faire en sorte que ça puisse être exécuté sur votre infra,
parce que le jour où vous aurez un problème de perf, ça va être hyper galère pour mettre en place ces outils-là.
Alors que si vous passez du temps au début du projet pour avoir ces outils qui sont activables,
entre guillemets en un clic, ça va vous sauver les fesses le jour où vous aurez des problèmes.
Par contre, c'est quand vous êtes au début de votre projet, installer ces outils-là,
mais ne regardez pas forcément le... à chercher et optimiser votre produit,
rajoutez les fonctionnalités au fur et à mesure,
et quand vous aurez réellement des problèmes de performance,
concentrez-vous sur la partie performance,
mais avant de vous concentrer sur la partie performance, améliorer votre produit.
Mais faites en sorte d'avoir de l'outillage pour pouvoir regarder ces problèmes de perf le jour où vous en aurez.
On avait parlé... je ne sais plus dans quel épisode, on avait parlé des piliers de DevOps,
et notamment l'observabilité. Et Christophe, tu m'avais repris sur la partie ligne.
Donc, le ligne, c'est faire les choses qui sont importantes au moment où elles sont importantes,
et ne pas gaspiller de temps là où vous n'avez pas besoin de l'y passer du temps.
Et là, typiquement, c'est ça.
C'est si vous faites du Rust, regardez pour activer la possibilité de faire des flammes graphes dans votre code,
mais ne regardez pas le résultat du flammes graphes avant d'avoir des soucis de performance.
Et toi, Christophe, est-ce que tu aimes mettre le feu dans tes applications ?
Oui, j'adore ça. Alors, moi, j'aurais une autre approche que toi, étant donné que je suis très pro déploiement continu à ces mondadas.
À partir du moment où on peut déployer une nouvelle application, une nouvelle réalise rapidement,
je pense qu'on peut rajouter des briques de monitoring ou d'APM,
puisque c'est là dans l'article où j'utilise des APM,
mais en tout cas, pour voir des problèmes de performance dans le code,
il faut utiliser des APM, des applications de supervision de performance en français,
ou alors en effet, faire comme tu le dis, moi, je ne le ferai pas comme toi.
Je la jouterai au moment où j'en ai besoin, parce que ça me prendrait une semaine peut-être pour l'activer.
Mais ça nous prouve bien, oui.
Mais si tu le fais au moment où tu as le problème, tu n'as pas suffisamment de recul sur tes métriques
pour voir quand est apparu le problème et ainsi de suite.
Alors, oui, moi, je fais quand même une différence entre les APM et les outils de supervision de manière globale,
parce qu'en effet, il faut mettre des outils de supervision, quoi qu'il arrive,
et l'APM, comme c'est en plus un truc qui consomme quand même plus que juste un peu de supervision,
l'activer au moment où ça arrive, c'est bien.
Mais, oui, c'est ce que je vais dire.
Ça nous prouve bien que la supervision et mettre en place une supervision, c'est important.
Ben déjà, c'est important pour savoir ce qui se passe et puis pour savoir quand ça arrive.
Comme tu le dis, s'il y a des dégradations de performance,
qu'on peut monitorer, genre, une page internet ou une requête spécifique qui dérive dans le temps,
c'est bien de le voir avec des outils de supervision.
Oui, en fait, je ne voulais pas trop spoiler l'article, c'est des gens à les le voir.
Mais en fait, là, il y a vraiment la démarque, justement,
ça part entre guillemets de la supervision.
Oui, ils arrivent, ils font un premier graphe avec les percentiles,
donc ils voient qu'il y a un certain type de requête qui prend plus de temps.
Donc ça, ça se fait vraiment avec les outils de supervision et les temps de réponse,
simplement des requêtes et donc ils arrivent à affiner jusqu'à tomber sur le processus,
ou le type de fameux filtre qui pose problème.
Et ensuite, ça passe dans un deuxième temps où là, effectivement,
on y bascule sur les outils de filtre, enfin, entre guillemets sur un poste plutôt développeur.
Ils installent le flame graph, ils déterminent, ils voient effectivement que le filtre,
ils analysent la fonction du filtre et ils regardent
ce qui prend le plus de temps dans le filtre.
Et il trouve une optimisation, je ne peux pas décrire tout l'article,
mais il y a vraiment ce démarque qui, c'est pour ça que l'article, je pense, c'est vraiment intéressant.
Et encore une fois, ça reste, enfin moi, j'ai trouvé que ça restait vraiment,
pour le coup, ce cas-là, il n'arrive pas partout,
mais d'habitude, c'est quand même des choses assez pointues, etc. assez difficiles.
Là, je trouve que c'est vraiment palpable et compréhensible.
Et aussi dans la manière dont c'est écrit, il n'y a quasiment pas de code dans l'article.
C'est vraiment des explications et presque un rex, en fait, de comment il a fait quoi.
Moi, je voudrais remonder sur quelque chose qui est proche.
Souvent, quand on parle de DevOps, vous savez, on a eu beaucoup de débats sur OK,
c'est un DevOps qui fait de l'Ops ou c'est un Ops qui fait du DevOps,
parce qu'on est capables de faire les deux aujourd'hui.
Et en fait, moi, ce genre d'article, ça prouve bien qu'en fait, on a deux métiers différents.
Il y a les Devs qui ont fait produire du code et conçoivent des solutions logicielles.
Et il y a les Ops qui les exploitent et qui sont à même d'investiguer et de trouver avec l'aide des Devs,
évidemment, parce que tout ça, c'est compliqué, mais c'est les Ops qui ont la capacité et l'expérience
pour gérer la volumétrie.
Quand t'es Dev, et on l'a vu tout à l'heure, il y a un message de quelqu'un qui est Dev,
quand t'es Dev, t'as pas l'habitude et t'as pas conscience que la volumétrie peut être énorme.
Et quand tu développes une application, en fait, c'est pas ton problème de faire face à la volumétrie.
C'est quelque chose que tu vois en production.
C'est sûr, tu peux pas, au moment où tu développes une appli, te dire, OK, je vais avoir 10 000 personnes
en simultané qui vont faire telle requête.
Non, ça, c'est vraiment le rôle de l'Ops, de, OK, j'ai des problèmes de performance,
qu'est-ce qui se passe, j'ai combien d'utilisateurs, ma base de données, les surchargés,
j'ai combien d'enregistrements, enfin, tout ces trucs-là.
C'est le rôle de l'Ops de mener ces investigations et avec ou pas l'aide des Devs de trouver des solutions.
Et pour moi, c'est un des aspects du métier dont on parle pas assez, qui est à la partie que moi,
je adore, parce que l'investigation, j'ai toujours l'impression d'être cher de colme,
quand je fais ça, j'ai un problème, je vais aller voir, je vais remonter mes logs, je vais voir mes métriques.
Et donc, je trouve la solution du problème.
Et après, une fois que j'ai fait l'analyse et que j'ai trouvé où était le problème,
je file mon analyse à mes petits potes, les Devs, et je leur dis,
« Ben voilà, moi j'ai trouvé ça, il y a a a priori un problème ici.
Est-ce que vous pensez pouvoir résoudre le problème ? Je suis prêt à vous aider, puis on m'en parle. »
C'est normal parce que tu as besoin d'avoir aussi une connaissance métier, des fois assez profonde,
en tant que, hop, ce n'est pas forcément, partiellement.
Et donc là, par contre, là où je ne suis pas tout à fait d'accord à ce que tu dis,
c'est quand même au niveau du développement, par rapport à la complexité,
suivant ce que tu fais quand même, le développeur, il doit quand même avoir une notion
de ce qui va un petit peu en fonction de ce qu'il écrit, ce qui risque de se passer.
C'est-à-dire que s'il fait vraiment un code avec une complexité importante, forcément, ça ne va pas se quitter.
Alors, si c'est sur un produit complètement nouveau, donc tu ne sais pas quel va être, on va dire, l'usage,
et le nombre de personnes que tu vas voir là, oui, effectivement, c'est difficile de prévoir.
Par contre, si c'est par exemple une modification sur une appli existente,
ou tu connais un peu la volumétrie, là, tu peux quand même estimer un petit peu, voilà,
si tu t'embêtes à faire un nouveau un peu meilleur ou pas quoi.
Oui, mais tout, enfin, ça vient avec l'expérience, je pense, plus t'as de l'expérience,
plus tu penses à ce genre de choses.
Mais comme il y a quand même beaucoup de développeurs qui sont nos vis qui nous écoutent,
et qui nous écoutent, c'est pour ça que j'en parle aussi.
Nicolas, dernier truc à ajouter ?
Pas d'optimisation prématurée.
Oui, surtout qu'en plus, on pourrait se planter sur nos petits mises trop doux.
D'où le côté contre-intuitif, justement, le gars qui analyse, au début, se plante complètement.
C'est-à-dire s'il avait fait l'optimisation sans mesurer, clairement, un biais qui fait que l'humain est très mauvais
pour prédire des problèmes de performance.
Ce que j'ai tendance à dire, et ce n'est pas valable que pour l'informatique,
c'est valable pour les entreprises, et je le dis aussi en tant qu'amende du CS à main direction,
on ne peut améliorer que ce qu'on mesure correctement.
Donc, si on veut améliorer quelque chose, que ce soit un programme informatique
ou des process dans une organisation,
il faut mesurer les choses avant, pendant et après.
Et si on voit une évolution dans la mesure, c'est qu'on a réussi notre amélioration
et sinon, c'est qu'on s'est raté quelque part.
Mais de la même manière pour les APM, si tu les mets dès le début de ton projet,
si on me dit c'est lent, tu peux répondre, oui, mais c'est aussi long qu'avant.
C'est clair que si tu le mets au tout début, il n'y a pas de problème de performance,
il y a ton APM. Ah, je suis d'accord.
Bon, je vous propose qu'on passe à la suite.
Et avant de passer à la suite, si tu aimes ce podcast,
et tu veux t'assurer qu'il continue,
et si tu veux l'écouter encore longtemps, le meilleur moyen pour nous soutenir,
c'est via un don, comme l'a fait Rodin.
Rodin, il a fait un don sur Libéra Pay.
Tu trouveras un lien en description.
Et je remercie du coup Rodin qui a fait un don de 1€ par mois pendant 13 mois.
C'est l'un des premiers donateurs qui n'est pas secret,
parce que sur Libéra Pay, l'avantage, c'est que tu peux faire des dons secrets,
même si je connais certains de mes donateurs secrets,
mais comme ils ont décidé d'être secrets, je ne dirais pas qui c'est.
Mais tu peux aussi faire des dons nommés.
En tout cas, tu peux faire comme Rodin
et nous soutenir, ça nous aidera à payer les outils informatiques qu'on utilise,
justement pour enregistrer et héberger ce podcast.
La diffusion des compagnons du DevOps est produite à Libra.