Votre modèle sémantique tiendra-t-il la charge ?

Phare Data

0:00Votre modèle Power BI est rapide avec un utilisateur, mais tiendra-t-il toujours la charge quand 100 utilisateurs et des dizaines d'agents IA commenceront interroger votre modèle sémantique en même temps ? [musique] Ouais, bonjour et bienvenue sur Fardata, la chaîne qui éclaire vos données. Aujourd'hui, nous allons nous attaquer à une question très concrète. Comment savoir si un modèle sémantique Power BI tiendra réellement la charge ? Un modèle peut être parfaitement fluide pendant son développement, fonctionner sans problème avec quelques utilisateurs puis montrer ses limites lorsqu'il arrive en production et que les utilisateurs commencent à l'interroger simultanément. Alors, comment reproduire cette charge avant la mise en production ? Comment tester plusieurs utilisateurs et plusieurs requêtes en parallèle ? Et surtout, quelle métrique faut-il observer pour identifier les limites de votre modèle et de vos capacités ? C'est précisément ce que nous allons voir dans cet épisode. Sur Phare Data, notre objectif est simple, vous aider à y voir plus clair dans l'univers de la data, de la natalic et de l'IA. Chaque épisode est préparé par des passionnés avec l'envie de partager, d'apprendre et de rendre un sujet utile au plus grand nombre. Fardata est une chaîne ouverte. Alors, n'hésitez pas à nous suggérer des sujets ou même à venir partager votre expertise lors de futur épisodes. Et si le contenu vous plaît, pensez à vous abonner pour ne manquer aucune de nos prochaines publications. Cap sur épisode du jour. Pour nous accompagner aujourd'hui, j'ai le plaisir de recevoir Ashraf qui va se mettre dans la peau du client et Gassen qui a justement

Introduction

1:32travaillé sur ce type de problématique sur le terrain auprès de plusieurs clients. Bonjour et merci d'être avec nous aujourd'hui. Ashraf, tu es déjà intervenu sur la chaîne, mais est-ce que tu peux te représenter rapidement ? Oui. Alors euh ben je suis Hraf Cherkri euh partenaire solution architect chez Microsoft. Donc je travaille pour accompagner les partenaires dans les implémentations de Fabric, modernisation, mise en place de data plateforme et et autres. Super. Et Gassel, je te laisse commencer par te présenter, nous expliquer rapidement dans quel contexte tu as été amené à mettre en place ces tests. OK. Gestern Cody, je suis Fabric solution architecte chez VO. Euh j'ai été amené à intervenir chez un client pour un déploiement euh disons en masse et ouverture de service pour 500 utilisateurs. Et la question qui s'est posée dès le début, est-ce que notre capacité tiendra sur 500 utilisateurs divisé sur trois plaques géographiques sur trois faisceaux horaires ? Est-ce que on est sur la bonne capacité ou pas ? Donc, il ne s'agit plus seulement de répondre à la question "Est-ce que ma requête est rapide ?" Mais plutôt que se passe-t-il lorsque mon modèle est réellement utilisé ? Ashraf, tu peux nous mettre dans la peau de du client et de ton besoin ? Ouais. Euh bah pour le coup, euh le coup, chez moi les mon rapport fonctionne très bien. Ma maman et mes rapports fonctionnent très bien quand je suis tout seul à travailler dessus, à

Quelle capacité Fabric choisir ?

2:49les visualiser, potentiellement les éditer parfois. Euh mais euh je commence à avoir du coup l'obligation de l'ouvrir pour l'utilisation, l'exploitation à une majorité des euh des collaborateurs au sein de l'entreprise. On est environ 500 à vouloir les explorer euh de avec une fréquence un peu différente. et je m'inquiète un peu sur la capacité et sur la sur le fait que la capacité puisse tenir cette charge là sans devoir trop passer de temps à à faire de la maintenance ou à garder l'œil dessus. Donc je veux savoir quel comment bien dimensionner ma capacité pour répondre à ces besoinsl. Très bien. OK. C'est une question que tous les utilisateurs se posent, toutes les entreprises se posent, tous les clients se posent. Et dans ce contexte, quand on dimensionne une capacité, il y a deux

Deux risques à éviter

3:46risques à éviter. Soit notre capacité soit sous-dimensionné, c'est-à-dire quand on aura un nombre bien déterminé d'utilisateurs qui vont se connecter, on tomberra dans un throtling, on tomberra dans une expérience utilisateur un peu dégradée surtout pour une ouverture de service. C'est pas ce qu'on veut avoir surtout avec les métiers ou surdimensionner notre capacité. Je donne un exemple. Nous, on a besoin d'une F32, une F64, mais on met en place une F128. Certes, quand on aura pas des problèmes de performance, mais est-ce que on a besoin de payer autant pratiquement le double de ce qu'on a besoin pour répondre à ça ? Et pour ça, il y a des choses à mettre en place. Il y a des tests à faire. Il y a des tests de charge à faire. Bien évidemment pouriser une capacité, il y a deux questions à se poser. Déjà la première la volumétrie de données. Quand je dis la volumétrie de données, la volumétrie de notre modèle sémantique si on parle en importake. Et en second lieu, le nombre d'utilisateurs concurrents qui vont se connecter. Quand on a 500 utilisateurs, certainement les 500 ils vont pas se connecter au même temps, ils vont pas être à la même seconde, à la même minute connecté sur la plateforme surtout s'ils sont divisés sur différentes plaques géographiques América, Europe, Asie avec des faisceaux horrivis par 3. Même si on a 150 ou 200 utilisateurs, par expérience, on trouvera 15, 20, maximum 30 utilisateurs connectés sur le rapport, sur le modèle sémantique pour effectuer des requêtes. Et pour ça, on peut simuler des tests afin de se positionner sur la bonne capacité. Merci Rassan. Bah du coup, c'est je suis complètement d'accord qu'on veut absolument éviter de sous-dimensionner et surtout de surdimensionner parce que ça fait mal un peu à la poche. Euh mais pour le coup, je voulais bien comprendre comment on peut réalistiquement simuler ces ces ces scénarios là sans demander à une vingtaine de personnes à être connectées en même temps et prendre un peu de temps de tout le monde. Comment on peut potentiellement automatiser un peu ça ? comment on peut distinguer les différents profils des utilisateurs de personnes qui utilisent PowerBay, d'autres qui exploitent la donnée sur Excel. Comment on peut avoir aussi l'implémentation d'une logique de distinction de Roll ? Donc si on a l'URLS parce que je j'ai commencé à en mettre un peu sur mes sur mes sur mes rapports et sur mes modèles. Euh qu'est-ce que tu peux m'en dire là-dessus s'il te plaît ? OK. Euh, il existe bien un test de charge qui répond à toutes tes questions. Déjà, on peut simuler un nombre d'utilisateur, on peut mettre 20, 30, 10, 5 euh euh et c'est un paramètre

Simuler la charge réelle

6:44dans le test. Euh bien dit par rapport aux RLS, parfois on build un modèle sémantique sur les tests unitaire. Le modèle sémantique, il y a pas de lenteur. Par contre, quand on le met sur la plateforme, on pas les utilisateurs passeront par des RLS. Si on a une RLS sur plusieurs niveaux qui passe par plusieurs tables de bridge, il peut on peut avoir des euh des dégradations de performance. C'est du CPU derrière consommé et bien évidemment il va être répercuté sur notre euh capacité Fabric. Ils ont aussi toujours on parle que la partie rapport c'estàd la partie dax mais la partie Excel et TCD analyse with Excel sur les modèles sémantiques, elle est assez importante parce que derrière des requêtes MDX on parle de gros TCD derrière ça aussi on peut le simuler avec notre test de charge. Alors, tu as parlé des fichiers Excel qui peuvent te générer du MDX un peu aléatoire suivant les besoins des utilisateurs. Qu'en est-il ? Euh du DAX généré par les agents ? On peut imaginer qu'un data agent connecté à son sémantique modèle va aussi générer ben des requêtes aléatoires. Comment tu pourrais évaluer cette charge ? un data agent derrière comme tu viens de dire Romain, il va lancer des requêtes d'axes. Ces requêtes d'axe, on peut les récupérer. On se met avec euh du DAX Studio sur le modèle sémantique. On écoutera toutes les requêtes passées sur le modèle euh sémantique. On enregistre et c'est la même pratiquement la même manipulation qu'on va voir après avec du MDX. On les enregistre, on donne ça à notre script et va simuler ça sur 1 2 3 4 5 agent. OK ? On pourrait même imaginer du coup te connecter un log analytics qui écouterait tes modèles pendant une à deux journées. Tu récupères après tous les requêtes d'axes qui lui ont été envoyées et pour les insérer dans ton enjeu de test. Possible. Oui, l'essentiel qu'on récupère les requêtes d'axe, on le met sur un fichier Jon et après on donne ça au script. On peut simuler le nombre de users entre parenthèses nombre de users en parlant de nombre de des d'agents IA prévus pour ce besoin. Oui, c'est possible. Super. Euh merci Rassen. Je suis très intéressé honnêtement par la solution et l'approche, mais j'ai une question à clé. Euh de quoi euh aurons-nous besoin pour pouvoir effectuer ces tests, simuler euh les scénarios ainsi de suite ? Voilà l'environnement de test. On aura besoin d'une capacité euh approvisionner dans Azure du Payazugo. Derrière, on peut faire mettre du F4, du F16, 32 64 selon le cas euh et la capacité qu'on souhaite tester. On peut monter jusqu'à F128 de 56 si on a besoin. Et l'avantage, c'est que on effectue nos tests, on laisse ouverte jusqu'à ça se lise. Si on a effectué des surtout des opérations de background, après on ferme la capacité et on paye juste ce qu'on a consommé. ça de 1 de on aura besoin euh d'un modèle sémantique cible si avec RLS ou pas, ça dépend. ici avec wayes 3, on aura besoin aussi euh d'un rapport derrière et euh un TCD Excel héberger bien sûr le modèle sémantique sera hébergé bien sûr dans le workspace qu'on va créer au préalable et on on aura besoin de la Fabric métrique capacity et bien sûr la capacité qu'on a approvisionné elle se trouvera là-bas pour bien sûr monitorer tout ce qu'on avait fait les intervalle les pic est-ce qu'on est à 100 % 60 est-ce qu'on est à 200 après on verra bien j'ai effectué plusieurs tests et on va le voir ensemble concrètement quelles vont être les étapes de cette mise en œuvre OK première étape on va commencer les tests on va commencer des tests de charge. Je je conseille qu'on commence par approvisionner par exemple une capacité si notre modèle peut tenir sur une capacité F64 côté euh volumétrie du modèle. On commence par une F64. On commence nos tests disant qu'on sait très bien qu'on va être maximum sur 30 users. On commence par 10 et après on commence à augmenter petit à petit. voir le comportement du modèle, voir le comportement de la capacité, c'est quoi les métriques euh qu'on peut euh avoir ? 2è phase, c'est analyser métrique. Déjà sur euh et on va voir après euh sur le script, ça nous donne le maximum des requêtes, combien de requêtes passées ? Euh bien sûr le CPU consommé par seconde. Et le point très important si on parle de la capacité, c'est est-ce qu'on est à 100 % dans notre capacité ou pas ? Est-ce qu'on est à 200 ou 300 % ? Ça c'est la phase d'analyse 3. Cette analyse on va un peu la comparer aux analyses que au monitoring qu'on avait fait en mode test unitaire. Si sur nos tests unitaires toutes nos requêtes passent à 3 4 secondes, après quand on est sur du service, ça passe à 10 12 secondes. Là, on sait très bien qu'il y a un problème, il faut l'identifier. Est-ce que c'est un problème d'ls ? Est-ce que quelque chose, c'est quoi le botton neck ? ça nous a le ce genre de test ça va nous aider à identifier ça derrière s'il y a une optimisation à faire bah on optimise le modèle bien sûr et bien sûr après on peut refaire le test de nouveaux faire de nouveau les observations et bien sûr validation des gains. Est-ce que sur suite à ces optimisations ? Bah du coup c'est toujours très intéressant pour moi REN la seule question que j'ai pour toi est-ce que tu peux nous montrer ça en en vraie vie ? Exactement, c'est ce qu'on va voir tout de suite. Alors, ashraf, euh notre script se trouve dans notre ripoit.

Demos

12:55C'est un script de David Bro. Euh voilà les informations du script. Là, on va voir euh comment euh mettre les paramètres. Chaque paramètre sert à quoi exactement pour notre pour nos simulations. Euh, les houseous name si on a un layout, le workspace, le schéma. La partie ici, c'est très importante, elle est très importante, pardon, combien d'utilisateurs on souhaite simuler. Ça simule aussi euh le thinking, c'est le l'utilisateur. C'est c'est une vraie simulation parce que c'est pas un script en mode on lance toutes les roquettes en même temps direct mais vraiment il y a une séparation entre les requêtes comme si c'est un vrai utilisateur derrière qui réfléchit, il est devant un report, il regarde, il est en train d'interpréter les chiffres, après il passe à autre chose. C'est ça. Alors il y a plusieurs solutions aujourd'hui. Je crois qu'il y en a une aussi sur la Fabric Toolbox. Pourquoi tu as choisi celle de David Brown ? Effectivement, celle qui existe sur la toolbox, je l'ai utilisé, n'est pas mal aussi, mais j'ai retenu euh la solution de David Brown par rapport à ça. Vraiment, c'est une simulation, on simule vraiment comme si c'était un vrai utilisateur derrière qui est en train de naviguer sur son rapport. Et il y a il y a plusieurs paramètres que on peut changer et on peut simuler des cas comme on souhait. Par exemple ici la durée euh du test bien évidemment nonateur concurrent et aussi ça la partie RLS. Je l'ai testé aujourd'hui, je vais pas le faire pour des besoins de confidentialité les adresses mail, mais quand j'ai testé, quand j'ai mis DAC Studio derrière, je voyais pas que mon nom qui est en train d'exécuter les requêtes, mais plutôt les adresses mail et les et les noms des personnes réellement que j'ai approvisionné dans le test. Et ça c'est très important. Et tu utilises le endpoint XMLA pour te connecter au sémantique modèle ? Oui. OK. OK. Ça c'est les paramètres. Après, ici, on parle des graphes euh la partie euh des requêtes euh le max euh des requêtes passé sur le euh sur le modèle sémantique. Ça c'est les queries par seconde. Et on voit bien ici, ça c'est c'est une euh c'est un screenshot de simulation de je pense de 100 users en même temps. Le script n'a pas balancé les 100 users en même temps mais plutôt ça commence avec petit à petit jusqu'à on arrive sur les 100. C'est pour ça j'ai dit c'est une vraie simulation et c'est mais c'est très bien. Après ici sur le dernier graphe, on peut voir la partie occupation ou la partie consommation de CU par seconde. Et ça c'est très important. Vous le voyez comme vous le voyez ici si on commence à avoir du throttling sur nos requêtes, le throttling, c'est le retardement des requêtes quand on consomme ce que la capacité nous autorise sur un lapse de temps bien déterminé. Là, on va voir ce petit fameux graphe très en jeune. Et là, on sait très bien qu'on est vraiment parti dans le trot. Ouais. Du coup, Rassen, tu me parles depuis tout à l'heure de de de script et tout. Est-ce que c'est des c'est des exécutions qu'on fait du via notre machine locale ? Est-ce que c'est des choses qu'on fait tourner sur sur Fabric ? Ça se représente comment ? Ça tourne sur Fabric. Voilà le notebook. On le télécharge directement, on l'importe dans notre workspace comme maintenant je vais partir sur Fabric. Alors, faudrait pas le faire tourner sur ta même capacité, j'imagine. Bah, c'est fait pour pour que ça tourne sur la même capacité. OK. Et voilà, c'est notre notebook. OK. Juste on vient ici, on télécharge le notebook. On peut me faire du copiercollé, hein, c'est facile à mettre en place. Et dans le notebook, il y a ici la partie source. Et là, on va mettre les gens de nos requêtes. On trouve ici ce qu'on s'est dit tout à l'heure, la partie durée, la partie utilisateur concurrent. Euh ça c'est des graphes de test ici. Ça te donne aussi l'exécution s'il y a des requêtes failed ou pas. Et ici c'est des tests que j'avais lancé moi auparafant. OK. Et pour le Gizon, du coup c'est les ce sont les requêtes d'Ax qui sont dans exécuté par mon rapport PowerBa que je veux tester. Exactement. C'est c'est soit des roquettes d'Ax, soit des requêtes NDX exécuté sur le modèle sémantique. Je pense qu'on va commencer par les requêtes MDX. Et et du coup, si on revient sur la petite question de Romain, le fait d'utiliser ce d'exécuter ce notebook sur le même sur la même capacité qu'on souhaite tester et pousser un peu, ça pose pas de problème ? Honnêtement, ça pose pas problème euh parce que c'est pas le notebook qui va consommer, c'est c'est vraiment juste les roquettes. Certes, il y a une petite consommation parce qu'on va l'exécuter derrière, mais c'est pas ça, j'ai envie de dire, qui va faire la différence parce que nous ce qu'on va regarder, c'est plus les requêtes en mode interaction et pas les requêtes en mode background. Et aujourd'hui, je vois que c'est du Park, mais on pourrait peut-être l'adapter aussi pour qu'il soit plus light sur du Python. Sur du Pyon, oui. À voir si c'est possible. Oui. OK. On peut l'adapter pour que ça soit plus light sur du Pitan. Je suis tout à fait d'accord. Comme on s'est dit, la première chose à faire, c'est se connecter sur le modèle avec DAX Studio pour récupérer le requête MDX. Mettre ici all query. Pourquoi ? pour voir toutes les requêtes qui passent au niveau. C'est un traceur en fait au niveau du modèle sémantique. Là on a notre fichier Excel. C'est un fichier Excel classique hein. C'est le modèle on a pris j'ai pris un modèle juste pour la démo, un modèle euh classique qu'on peut trouver sur internet. J'ai mis les country, les states, les dates, des chiffres qu'on peut trouver dans n'importe quel modèle sémantique, total cost quantity, c'est les amin et j'ai fait un peu exprès pour que ça soit un peu gros une grosse matrice avec toutes les dates qui dans le modèle. Maintenant ce que je vais faire c'est imaginons que je suis un utilisateur, j'ai déjà buildé mon mon DCD et chaque matin, j'arrive, j'actualise mes chiffres pour voir. Je lance l'actualisation. Et normalement, si je pars sur du DAX Studio, voilà, là je vois les requêtes passer. Après, j'exporte et là, on va faire une petite manipulation pour que les roquettes MDX soient euh interprétées par le le script. J'exporte mes euh mes requêtes, je l'ai fait moi déjà. Je mets ici, j'enregistre et après euh ici, pardon, je l'enregistre et après ici, on a converted. Je vais vous montrer comment faire pour que ça soit interprété par euh le script. Là, il y a euh une petite fonction euh Python. On peut vous le mettre après même dans la description de la vidéo. Il faut l'exécuter avec la commande invite commande CMD pour que cette commande soit exécutée et elle vous convertit de votre fichier de requête celui-là pour que ça soit interprété. un un autre test que j'ai effectué sur du DAX. Je vais le supprimer ce fichier et là je vais chercher le fichier que j'ai converti. C'est bon, c'est chargé. C'est chargé correctement. Là, je vais diminuer quand même 730, c'est beaucoup. Je pense que je vais mettre on commence petit si on veut dire ça. On commence par exemple avec 5 utilisateurs parce que notre modèle je vais mettre sep utilisateurs parce que notre modèle il est il est petit quand même. C'est c'est pas vraiment le modèle cible. Et juste pour info, je suis aussi sur une petite capacité sur une F4. OK. Mais ce n'est bien que pour la démo rien l'empêche de changer selon ce que ce que j'ai chez dans dans mon entreprise avec le nombre d'utilisateurs qui utilise Excel et tout ça. Tout à fait. Et ici juste pour le besoin de la démo, mais vu qu'on est sur une capacité Paz Hugo, on peut la monter jusqu'à NF64, F128, comme on veut selon nos besoins et bien sûr le modèle adéquat. Mais là c'est un petit modèle, c'est une petite capacité. Et là, ce qui nous reste à faire, c'est vraiment je vais revenir quand même sur DAX Studio. Je vais faire clear. Vo ici euh sur cette sur la ligne 50, on peut mettre si euh il y a de l'RLS là-dessus, on peut mettre les adresses mails des personnes qu'ils auront ou qui passeront par les RLS de ce modèle. Aujourd'hui, pour les besoins de démo, on l'a pas. OK. Et pour la partie configuration RLS, je suppose que tout est bien documenté sur le sur le Ripo. OK. Tout à fait, tout à fait. Et là c'est facile. Il faut juste récupérer les adresses mail, faire les mettre ici, faire c'est pareil par virgule et on peut mettre le nombre d'utilisateurs qu'on souhaite pour que vraiment on simule, c'est l'exécution d'un vrai utilisateur. Et là euh je vais lancer. Alors, tu as toujours ton DAX Studio qui écoute. Donc, j'imagine que tu vas voir ce que génère ici ton notebook en terme de query. C'est ça. Est-ce que tu es pas intrusif aussi en écoutant ? Voilà, les premières requêtes arrivent. Bah là parce qu'il y a que moi qui lance euh user, il y a que moi. Non, mais si on [grognement] avait des personnes euh pour RLS, on verra bien aussi euh ces personnes-là, leur nom apparaissent ici. Oui, l'écoute n'est pas intrusif.

23:30Non non gardes les résultats dans un house ? Ouais. Non, c'est les utilisateurs que j'avais mis. Je vois qu'on a bien les les métriques sur l'utilisation du CPU et tout ça. Ouais. Et on va le voir même sur format de graphe après. OK. Là, je reviens juste sur un paramètre. En gros, moi j'ai précisé ici le workspace target et et le target dataset parce que j'en ai deux et si on a pas on peut le pas mettre et déjà c'est stipulé dans la documentation du script. Ouais. Voilà on n pas de de fail failed. OK c'est bon. Je dis je conclus que sur ce passage pardon, on n' pas de throtling, pas de retourner parce que là il doit nous afficher euh la partie graphe. Je pense que les exécutions sur du Dax, c'est fini. Ouais, c'est c'est fini les exécutions. On a plus de nouvelles requêtes sur le modèle mais là c'est juste le notebook qui exécute le reste. Bon notebook c'est c'est bon, c'est terminé. Là on voit les graphes. Là c'est les durées. On a des requêtes qui ont duré vu que c'est du MDX derrière et vraiment une grosse matrice, il y a des requêtes entre 22 et jusqu'à 37. seconde sur le modèle. Ça c'est le nombre de requêtes passé par seconde. Les utilisateurs ici comme on le voit, on a commencé par 2 4 6 après en arrivant auutilisateur mais pas directement 7 en même temps. Là c'est un peu le CPU par seconde l'occupation du CPU par seconde. On n' pas d'autres hling, on est bon. Mais on verra bien, même si on n pas d'autres hing la consommation notre capacité. Et là euh je vais partir pour actualiser notre rapport métrique capacity l'application. On était à casache froid, à cash chaud les requêtes. Est-ce qu'il a clearé le cache à un moment donné ou euh ça c'est notre première exécution, du coup il y a pas de cache. OK mais les la deuxième query a utilisé le cash de la première. Je sais pas. Non. Et ça c'est un point c'est c'est c'est le point aussi pourquoi j'ai choisi la solution euh de David. Parce que vraiment il est derrière euh il y a pas de cache. La première il y a pas la deuxième il y a pas de cache de la première query même si je suis le même utilisateur. Et là on peut le on peut le regarder ici sur le modèle pardon sur Dax Studio. Ouais. une voilà, on voit pas une requête à 30 secondes mais celle d'après à 2 secondes, tu vois. Et c'est pour ça euh la solution, elle est vraiment pertinente. OK. Alors, notre test est terminé et là, on est sur Fabric métrique app. Ça c'est notre test et on va voir derrière ce qui s'est passé. Et là, on verra bien les exécutions. Donc, tu as dépasser le seuil de cu que tu avais à disposition mais pour autant on n pas vu de throtling parce que tu as pas été au-delà du premier seuil des 10 minutes de surutilisation. Voilà. Là vraiment on est euh avec les se utilisateurs vraiment on est à 100 % de consommation de la capacité. disant que si on extrapole ça, si on reste l'exemple actuel avec la capacité actuelle avec la F4 qu'on a, si on lance cette personne exécuter le rapport de ou le TCD que j'avais montré tout à l'heure, vraiment on est pile poil de la capacité, on est à 100 %. J'ai envie de dire que il est plus judicieux de partir sur une F8. Après, bien sûr, en voyant si il y a des problématiques euh de type RLS ou autre, de mon côté, j'ai pas vu parce que quand j'ai exécuté le les euh le le TCD, quand j'ai exécuté aussi le modèle, il y a pas vraiment des problématiques. Et d'ailleurs, ce modèle, il y a pas du tout du RLS. Du coup, j'ai envie de dire que et pour répondre à Ashraf, notre décision là, si on part sur NF 8, ça serait plus judicieux. OK. Et je tiens à préciser un point. Euh quand on part sur une fuite et Romain, il peut donner ses idées. Certes qu'on va doubler de capacité, mais ça ne veut pas dire que ici par exemple, on a consommé 27 secondes sur une F8, ça va être 10 secondes. C'est pas du linéaire du tout mais ce qu'on va faire, je vais revenir ici. Quand on partira sur une fuite plutôt cette ligne de 100 % elle va être poussée plus loin et sur une fuite on consommera que 50 % de la capacité. C'est pour ça je te dis et je te suggère de partir par exemple sur une F8. OK. Ouais. Donc c'est c'est plutôt pour laisser un peu de la marge au niveau de capacité de calcul plus que accélérer les requêtes parce qu'en soit ça exactement. Après euh bien évidemment, ça c'est un test de simulation, c'est le monde approximatif, si on peut dire ça. Quand on mettra la capacité, certes, on va sécuriser l'ouverture du service euh au tout début, mais il faut toujours monitorer notre capacité, voir le comportement, est-ce que on a besoin d'ajustement derrière ? un minim, on a garanti l'ouverture de service qu'il y aura pas de problématique de performance pour les utilisateurs. Et aussi un point très important, on n' pas surdimensionné notre capacité. C'est-à-dire aujourd'hui sur une je suis sur une F4, bah si avec cet utilisateur j'ai trouvé que j'ai consommé que 10 %, je pense qu'on partira sur une F2 mieux que ça restir sur une F4. Si on extrapole ça peut-être si on était sur 928 je te dirais vraiment sur 928 on a consommé que 10 % on a consommé que 20 % de la capacité on vraiment on aura pas besoin d'une F 128 mais plutôt une F64 c'est dans les deux sens ça major du coup sur sur ce premier sur cette première simulation on a vu comment bien interpréter un peu les résultats et les graphes mais Si si tu peux me montrer un peu à quoi ça correspond quand il y a du trot ligne du coup pour savoir comment bien les interpréter. OK. Ben, j'ai effectué déjà un test auparavant avec un nombre d'utilisateurs beaucoup plus importants. Je pense j'étais sur plus que 20 utilisateurs en même temps. Je pense c'était une trentaine d'utilisateurs en même temps. Et là vraiment on a consommé 1000 % de ce qu'on devait consommer sur la capacité. Et là, on va voir euh qu'est-ce que ça donne comme résultat et après on va éclaircir le point du trot. OK, ça c'est le consommation et ça c'est le troting. OK. 40 secondes de throttling. 20 20 20 et ça et le throttling c'est euh réellement euh le retardement des requêtes derrière. C'estàd même si notre requête elle peut s'exécuter en 2 3 secondes, ben il faut rajouter 20 secondes à chaque fois. Et là vraiment on passe ce qu'on appelle euh la dégradation de l'expérience utilisateur et on aura tout le monde qui va se dire voilà le modèle sémantique il n'est soit il n'est pas performant ou euh vraiment la plateforme n'est pas performante puis ça n'a pas ce qu'on a envie d'avoir. Ouais on voit ta grandir là en bas dans la partie overage on peut citer les capacités overage maintenant qui permet de se donner un peu de marge sur une capacité plutôt que la doubler. On pourrait se dire tiens ben jaloux 100 euh CU en plus en cas de besoin et donc ce Capacity overage viendrait consommer en plus de notre capacité sur Azure euh un peu un peu un peu de coût quoi. Exactement. Mait d'absorber cette charge. Exactement. Temporairement quelque chose qu'on veut toujours arriver quoi. Euh c'est c'est un très bon point roman. OK. Euh très bon point roman. Euh effectivement, parfois on a des pics de capacité, mais c'est des pics périodiques. C'est-à-dire, on a ça une fois par 10 jours, juste la fin du mois. Dans ce cas-là, réellement, on va pas doubler de capacité mais plutôt activer les capacités overage, absorber ce surplus périodique et c'est tout. Et comme ça, on partira pas sur vraiment le double de notre capacité. Ah ok. Du coup, on a vraiment toutes les données des résultats d'exécution des du notebook qui sont exploitables via des tables et autres. Donc, j'imagine que rien n'interdit de pluguer un agent via Gitab Copilot ou autre dessus pour nous aider à première première vague effectuer une première vague d'analyse et je sais pas si ce que tu en penses sur la scène. C'est une bonne idée hein. Comme ça directement tu as tes résultats. L'interprétation de tes résultats. Oui, c'est top. tu poseras tes questions directement à ta à ton L et ça va servir comme source de données. Oui, même pour optimisation, j'imagine que je

33:56lui demande à partir des requêtes que tu as vu, est-ce qu'il y aurait des requêtes qui pourraient améliorer ? Ça pourrait être intéressant. Oui, intéressant. Je pense qu'on va commencer à l'utiliser tout de suite. OK, top.

Conclusion

34:12Alors, on l'a vu, hein, test de charge ne doit pas simplement nous donner un résultat du type ça passe ou ça passe pas. Il doit plutôt nous permettre de comprendre où se trouve la limite, ce qui consomme les ressources et quelle optimisation auront réellement un impact. tout à fait euh romain et en plus on a testé, on a mesuré nos consommations, on peut faire de l'optimisation derrière s'il y a des optimisations à faire et à ce moment-là on peut rejouer de nouveau le test, dimensionner nos capacités notre capacité de nouveau. Comme ça, on sécurise notre périmètre, on sécurise l'ouverture de service ou la migration ou la mise en place d'un nouveau use case. On garantit la performance, on garantit une expérience utilisateur fluide avec une stabilité plus des maîtrise des coup. Ouais. du coup et pour moi Ren, merci beaucoup pour la présentation et la démo. Ça m'a beaucoup convaincu et là je pense qu'on a trouvé le prochain outil à rajouter à notre stack de de monitoring de de et de maintenance et d'administration de notre plateforme du coup qui va forcément être automatisé à un moment donné pour garantir que les optimisations et les bandes des dimensionnements soient une pratique continue au sein du au sein du groupe. Merci beaucoup. OK. Très bien. Vous avez maintenant une vision plus concrète de ce que peut apporter un test de charge sur un modèle sémantique. Finalement, le message à retenir est assez simple. un modèle performant pour un utilisateur n'est pas nécessairement un modèle performant pour son utilisateur. Et donc avant une mise en production importante, le test de charge permet justement de confronter notre architecture à des conditions plus proches de la réalité, d'identifier ses limites et de comprendre où concentrer les optimisations. L'objectif n'est pas de chercher une capacité capable d'absorber n'importe quelle charge. et plutôt de trouver le bon équilibre entre architecture, optimisation du modèle, expérience utilisateur et capacité nécessaire. Merci Gassen et Ashraf pour leur explication, leur retour d'expérience et la super démonstration. Donc si vous avez réalisé déjà des tests, n'hésitez pas à nous mettre dans les commentaires vos retours d'expérience. Vos méthodes et vos résultats pourront certainement aider aussi d'autres membres de la communauté. Et si cet épisode vous a été utile, pensez à vous abonner à Fardata et on vous dit à très bientôt pour un nouvel épisode.