ASP.NET: profiler une application

Voici une information bien intéressante reçue de la part de mon cher collègue PMI qui m’a permis de la partager ici. Alors voila, je vous en fait profiter Image may be NSFW.
Clik here to view. :

Il vous est probablement déjà tous arrivé de vouloir comprendre pourquoi/où votre application,  ou une partie de celle-ci était lente.
Vous savez peut-être aussi qu’il existe un profiler dans la version Visual Studio 2008 Team System. Si vous aviez essayer de l’utiliser, vous vous étiez peut-être rendu compte que ce n’était pas trop compatible avec une compilation NAnt et que, quand ça marchait, les résultats n’étaient pas toujours lisibles car le pre profilé était principalement le pre du framework .NET…

Voici quelques commandes qui devraient vous aider.

En pré-requis:

1. Je vous suggère fortement d’ajouter « C:Program FilesMicrosoft Visual Studio 9.0Team ToolsPerformance Tools » à votre Path.
2. Il faut connaitre la différence entre sampling et instrumentation.
   En gros, sampling est plus général et instrumentation plus détaillé. La collecte des données ainsi que la génération des rapports en est autant plus longue.
   D’après la littérature, il semble que quand on cherche un bottleneck dans une application non ASP.NET, il faut mieux commencer par faire un sampling. Ce n’est pas la cas pour les applications ASP.NET car on se retrouve avec les méthodes du framework et de l’ASP ce qui n’est pas très intéressant.

Je veux profiler un service windows -> sampling

1. Dans VS -> Analyse -> profiler -> New performance session
2. Ouvrir une ligne de commande : vsperfclrenf /globalsampleon
3. Redémarrer le service à profiler
4. Dans la fenêtre Performance Explorer, cliquer sur Attach, sélectionner son service et c’est parti…

Je veux profiler une application asp.Net -> instrumentation

Ici, il va falloir utiliser ses petits doigts. On va générer un fichier en ligne de commande et ensuite le lire avec VS.
On ouvre une première ligne de commande et on se place dans le répertoire des dlls à auditer.

1. vsperfclrenv /globaltraceon
2. iisreset
3. vsinstr madll.dll
   • On doit taper cette commande pour chaque dll qu’on veut profiler.
     vsinstr *.dll ne fonctionne pas.
   • Cette commande modifie la dll en y ajoutant des commandes de « log ».
     Faites très attention à ne pas publier ces dlls en PROD car elle ssont plus lentes et potentiellement plus facile à reverse engineerer
   • Pour info, il est recommandé d’exécuter cette commande sur des dlls compilées en mode release avec lesquelles on a copié les fichiers *.pdb de debug.
4. vsperfmon /TRACE /output:monfichier.vsp /user:ASPNET

Cette ligne de commande va collecter les informations.
Vous pouvez démarrer vos tests/scénario sur votre application ASP.NET locale.
Quand vous avez fini, ouvrez une 2eme ligne de commande et replacez-vous dans le répertoire précédent.

1. iisreset -stop
2. vsperfcmd –shutdown
3. vsperfreport monfichier.vsp /PACKSYMBOLS
   • Ça prend un peu de temps et ça permet de résoudre les noms des symboles contenu dans les fichier *.pdb.
     Le fichier de résultat est ensuite lisible depuis n’importe où et n’importe quand.
4. iisreset –start
   • Ça permet de pas s’énerver en se demandant pourquoi son site ne fonctionne plus Image may be NSFW.
     Clik here to view.
5. vsperfclrenv /globaloff

Il ne vous reste plus qu’à ouvrir votre fichier dans Visual Studio (ça va prendre un petit peu de temps car les rapports vont être générés). Ensuite y a plus qu’à regarder…