Voilà une discussion que j’ai souvent avec des clients :

Eux : “Bon, maintenant je sais que cette pages est gourmande, elle est longue à exécuter, elle consomme du temps processeur… mais comment je sais où est le problème ‘dans le code’ ?”

Moi : “Et bien il suffit d’utiliser le profiler de Visual Studio pour obtenir les temps d’exécution des méthodes par exemple, et d’isoler le code coupable. L’idéal, c’est de lancer le profiler pendant un test.”

Eux : “On peut faire ça à distance ? Pendant que j’exécute mon test de montée en charge ?”

Moi (Faiblissant) : “Euh… non…” (Pas dans la version 2008 en tout cas :-))

Bref, tout ça pour dire que non, on ne peut pas profiler à distance un site ASP.NET. Mais ça n’est pas trop important, car en attendant une prochaine version, il existe des solutions :

·       Profiler l’application en local, en exécutant un test de charge léger sur celle-ci. L’idée est d’avoir un point de référence en termes de temps d’exécution sur la machine de développement. On pourra alors facilement relancer une séance de profiling sur la même machine après une phase d’optimisation et comparer les rapports (avec l’outil intégré, c’est un jeu d’enfant)

·       Installer Visual Studio sur la machine testée. Si, si. Et je te vois, lecteur averti, me maudire virtuellement à coup de “C’est pas propre”, “Ca va fausser les résultats” et autres révolteries. Mais bon, il faut avouer que le plus souvent, la solution la plus simple est de lancer le profiling directement sur le serveur (En continuant bien entendu à exécuter le test de charge à partir d’une autre machine !)

·       La dernière solution est d’installer uniquement la “partie profiler” de Visual Studio, appelée “Stand-alone Profiler”. Cela met à disposition les exécutables utiles au profiling… qu’il faudra appeler manuellement pour instrumenter les assemblies, démarrer la collecte des résultats, générer le fichier de rapport (.vsp) qu’on pourra ensuite récupérer et analyser dans un Visual Studio sur une autre machine.

Dans tous les cas, je vous conseille de toujours simuler l’activité de votre application via un test automatique lorsque vous la profilez. Vous pourrez ainsi plus facilement refaire une phase de profiling par la suite qui générera une activité identique et permettra une comparaison des résultats beaucoup plus réaliste.

Pour plus d’information sur le profiling de Visual Studio 2008 en général, je vous redirige vers cette page de la MSDN : http://msdn.microsoft.com/fr-fr/library/bb385770.aspx

Concernant le profiling via le Stand-alone profiler, je vous conseille un très bon article de David Gray (en anglais) : http://blogs.msdn.com/graycode/articles/AspNetOffRoadProfilingArticle.aspx ainsi que la référence MSDN des commandes disponibles pour chaque étape de profiling : http://msdn.microsoft.com/fr-fr/library/ms182401.aspx

Bon profiling ! :)

.Dispose();