Profilage

Par où commencer ?

Dans les applications modernes, qui sont souvent découpées en une multitude de projets, il est parfois difficile de savoir par où commencer notre analyse des performances. Si un scénario bien précis a été identifié, il faut le reproduire localement afin de pouvoir déterminer à quel moment se produit le goulet d’étranglement, et ainsi identifier le ou les projets concernés.

Cependant, comme cela a été dit précédemment, l’optimisation des performances doit s’intégrer dans le processus normal d’écriture d’une fonctionnalité. Et généralement, à ce moment précis, aucun scénario en particulier ne s’est dégagé. Ainsi, il apparaît plus difficile de trouver par où commencer.

Une approche serait de mettre autant de profilers que nécessaire sur chaque projet en relation avec la fonctionnalité pour arriver à trouver d’où pourraient provenir les ralentissements. En choisissant cette approche, le système au global serait ralenti par les profilers et pourrait donc amener à détecter de faux positifs.

Dans le cas d’une architecture moderne, avec un front-end et un back-end, la question de la performance brute est souvent adressée de façon quasi-exclusive au sein...

Scénarios de profilage

Comme nous l’avons expliqué dans le premier chapitre, il est important de se baser sur des scénarios bien déterminés sur lesquels nous souhaitons améliorer la performance. Nous allons préparer deux scénarios, avec pour but d’améliorer le temps passé dans chacun d’eux, mais également de limiter les ressources consommées.

Vu la faible complexité de l’application de démonstration, ces deux scénarios couvrent la quasi-totalité des interactions disponibles.

1. Premier scénario : afficher le détail d’une personne

Pour ce tout premier scénario, nous allons réaliser une série d’interactions simples. Nous commençons par nous connecter :

Étape de connexion

Le système d’authentification est très simple : il consiste à inverser l’ordre des lettres du login pour obtenir le mot de passe. Ainsi, le login "admin" aura comme mot de passe "nimda". Cela fonctionne pour n’importe quel login, étant donné qu’il n’existe aucune table d’utilisateurs.

La façon dont l’authentification est réalisée ne respecte aucune bonne pratique de sécurité. Ainsi, un cookie est déposé sur l’application, avec la clé...

Lancement du profilage

À l’aide des scénarios retenus précédemment, il nous est dorénavant possible de lancer de façon effective le profilage.

Lançons la solution Profi (depuis le répertoire AvantOptimisation) dans Visual Studio 2022 afin de commencer notre investigation. La première étape va être de profiler la consommation de mémoire et CPU de l’API au fur et à mesure de l’exécution des scénarios. À cet effet, l’instance de Visual Studio 2022 sera dédiée à cette surveillance.

1. Profilage de l’API : premier scénario

Nous allons commencer par profiler l’API afin de voir les pertes de performances brutes, et ce peu importe le client utilisé.

Tout d’abord, il faut s’assurer que le projet de démarrage est bien Profi.API (1) et que le mode de compilation est bien sûr Release (2). Ces informations se trouvent généralement dans la barre d’outils de Visual Studio 2022 :

Barre d’outils de Visual Studio

Si tout est correctement configuré, on peut dès lors commencer à configurer la session de profilage, en ouvrant le menu Déboguer (1), puis en sélectionnant Profileur de performances (2). Ceci peut également être fait en utilisant le raccourci par défaut [Alt][F2].

Menus pour lancer le profileur

Lorsque la configuration du profileur est lancée, nous choisissons de cocher une seule métrique : Utilisation de l’UC.

Configuration de la session de profilage

Nous nous assurons que la cible choisie est bien Profi.API. Sinon, il suffit d’utiliser le menu en haut à gauche pour sélectionner Changer la cible et choisir Projet de démarrage. Avant de démarrer le profilage et pour éviter de perdre du temps, il est recommandé de lancer directement le projet client. Pour ce faire, on ouvre une invite de commandes dans le répertoire du projet Profi.Client, au même niveau que le fichier csproj, et on écrit la commande suivante :

dotnet run 

Le client se lance dans la console (on peut faire un [Ctrl] + clic sur le lien afin de l’ouvrir directement dans le navigateur par défaut).

a. Exécution avec profiler

Avant de démarrer de façon effective le profilage...

Conclusion

Nous avons terminé d’optimiser la partie serveur de notre système, et nous avons vu dans ce chapitre comment analyser les résultats afin d’en tirer les conclusions qui s’imposent.

Bien sûr, les chiffres seront uniques selon chaque environnement d’exécution, ceux publiés ci-dessus sont donc purement illustratifs. Dès lors que nous jugeons le gain en performance assez significatif, il convient d’arrêter le processus de profiling et d’optimisation.

Comme cela a été dit au début de cet ouvrage, le but n’est pas de faire du tuning et de gagner quelques millisecondes, mais bien d’optimiser pour gagner suffisamment en performance pour que cela soit ressenti par l’utilisateur. Au final, si l’on doit synthétiser le résultat de notre session, on constate que :