{"id":1055,"date":"2016-07-20T15:56:53","date_gmt":"2016-07-20T13:56:53","guid":{"rendered":"http:\/\/blogs.msdn.microsoft.com\/lavanack\/?p=1055"},"modified":"2022-05-30T13:52:01","modified_gmt":"2022-05-30T11:52:01","slug":"performances-exceptions-asp-net","status":"publish","type":"post","link":"https:\/\/laurentvanacker.com\/index.php\/2016\/07\/20\/performances-exceptions-asp-net\/","title":{"rendered":"Exceptions ASP.Net et Performances \/ ASP.Net Exceptions and Performance"},"content":{"rendered":"
Go to the English version<\/a><\/div>\n

Lors de mes visites chez mes clients il m’arrive souvent de v\u00e9rifier la configuration ASP.Net et de jeter un coup d’oeil rapide aux performances de leurs applications. Je laisse l’expertise approfondie \u00e0 mes coll\u00e8gues PFE D\u00e9veloppement. Hormis le mode debug<\/a> activ\u00e9 sur au moins une application de production chez 50% des clients (pensez \u00e0 bien v\u00e9rifiez chez vous et \u00e0 revoir vos processus op\u00e9rationnels en cons\u00e9quence), je collecte g\u00e9n\u00e9ralement des donn\u00e9es de performances (id\u00e9alement sur 24 heures) via Performance Monitor (aka PerfMon). Je vous livre m\u00eame ci-dessous mon script pour lancer le tout depuis une ligne de commande :<\/p>\n

\r\nREM To create a Data Collector Set with the appropriate Performance counters for an IIS server (every 15 seconds during 24 hours)\r\nlogman create counter %COMPUTERNAME%-IIS -v mmddhhmm -o %SYSTEMDRIVE%\\PerfLogs\\Admin\\%COMPUTERNAME%-IISPerformanceCounters -f bin -rf 24:00:00 -si 00:00:15 -c "\\.NET CLR Data\\*" "\\.NET CLR Exceptions(*)\\*" "\\.NET CLR Interop(*)\\*" "\\.NET CLR Jit(*)\\*" "\\.NET CLR Loading(*)\\*" "\\.NET CLR LocksAndThreads(*)\\*" "\\.NET CLR Memory(*)\\*" "\\.NET CLR Networking(*)\\*" "\\.NET CLR Remoting(*)\\*" "\\.NET CLR Security(*)\\*" "\\.NET Data Provider for SqlServer(*)\\*" "\\Active Server Pages\\*" "\\APP_POOL_WAS(*)\\*" "\\ASP.NET Applications(*)\\*" "\\ASP.NET Apps v1.1.4322(*)\\*" "\\ASP.NET Apps v2.0.50727(*)\\*" "\\ASP.NET Apps v4.0.30319(*)\\*" "\\ASP.NET v1.1.4322\\*" "\\ASP.NET v2.0.50727\\*" "\\ASP.NET v4.0.30319\\*" "\\ASP.NET\\*" "\\Cache\\*" "\\Distributed Transaction Coordinator\\*" "\\HTTP Service Request Queues(*)\\*" "\\HTTP Service Url Groups(*)\\*" "\\HTTP Service\\*" "\\Internet Information Services Global\\*" "\\LogicalDisk(*)\\*" "\\Memory\\*" "\\Network Inspection System\\*" "\\Network Interface(*)\\*" "\\Paging File(*)\\*" "\\PhysicalDisk(*)\\*" "\\Process(*)\\*" "\\Processor Information(*)\\*" "\\Processor(*)\\*" "\\Server\\*" "\\System\\*" "\\TCP\\*" "\\TCPv4\\*" "\\TCPv6\\*" "\\W3SVC_W3WP\\*" "\\WAS_W3WP(*)\\*" "\\Web Service Cache\\*" "\\Web Service(*)\\*" \r\nREM To start the Data Collector Set \r\nlogman start %COMPUTERNAME%-IIS\r\n<\/pre>\n
<\/p>\n
Je laisse ici l’emplacement par d\u00e9faut (%SYSTEMDRIVE%\\PerfLogs\\Admin\\%COMPUTERNAME%-IIS) pour le fichier g\u00e9n\u00e9r\u00e9 (*.blg) que vous pouvez bien entendu changer.<\/p>\n
Ensuite une macro analyse avec PAL<\/a> (si vous ne connaissez pas PAL<\/a> je vous conseille tr\u00e8s vivement<\/strong> de lire cet article<\/a>) vous donnera un aper\u00e7u rapide de la performance du ou des serveurs. Mais l\u00e0 n’est pas le but de cet article.<\/p>\n
J’aimerai ici me focaliser sur les exceptions .Net et leur impact sur la performance de vos applications Web\/ASP.Net. Comme expliqu\u00e9 sur https:\/\/msdn.microsoft.com\/en-us\/library\/ff647791.aspx<\/a> (cf. Exceptions). Les exceptions CLR .NET sont observ\u00e9es \u00e0 travers le compteur de performances \u201c.NET CLR Exceptions, # of Excepts Thrown<\/strong>\u201d <\/span><\/span>(Ce compteur indique le nombre total d’exceptions g\u00e9n\u00e9r\u00e9es par seconde dans le code manag\u00e9). <\/span>La recommandation est de rester proche de 0. Une application qui g\u00e9n\u00e8re des exceptions peu<\/span><\/span>t avoir des bugs ou utiliser le m\u00e9canisme d’exceptions comme partie int\u00e9grante de la logique m\u00e9tier. <\/span>Cette derni\u00e8re utilisation est d\u00e9conseill\u00e9e car les exceptions sont tr\u00e8s co\u00fbteuses et peuvent d\u00e9grader s\u00e9rieusement les performances de votre application. <\/span>Vous devez analyser votre code pour voir si celui-ci utilise des exceptions dans son algorithme. <\/span>Response.Redirect<\/strong>, Server.Transfer<\/strong> et Response.End<\/strong> provoquent une exception de type ThreadAbortException<\/strong> dans les applications ASP.NET. <\/span>Un serveur Web qui fonctionne bien ne doit pas g\u00e9n\u00e9rer d’erreurs. <\/span>Examiner et corriger vos bugs avant de faire des tests de performance et surtout avant de passer en production. <\/span>De plus, moins de 5 % de vos requ\u00eates ASP.NET \/ sec doivent avoir des exceptions .NET (compteur de performances \u201c.NET CLR Exceptions, # of Excepts Thrown \/ sec<\/strong>\u201d). <\/span>Si vous voyez plus de 1 requ\u00eate sur 20 lancer une exception, vous devez investiguer. Et c’est pr\u00e9cis\u00e9ment sur ce dernier point que je vous propose un script<\/a> PowerShell qui analysera vos fichiers de performances (*.BLG) et vous indiquera quand le seuil de 5% d’exceptions ASP.Net est d\u00e9pass\u00e9 (toutes applications confondues). Vous n’\u00eates pas oblig\u00e9s d’utiliser le jeu de compteurs que j’ai sp\u00e9cifi\u00e9 plus haut mais il faut au moins que les compteurs suivants aient \u00e9t\u00e9 collect\u00e9s :
\n<\/span><\/span><\/p>\n
 <\/p>\n