IIS/ASP.Net Performance Baseline

Lors de mes formations et de mes visites chez mes clients, j’aborde souvent l’aspect performances et je constate que beaucoup de clients ne collectent pas ou ne savent pas collecter les bons compteurs de performances pour IIS et ASP.Net. (Une pré-analyse peut ensuite être faite avec PAL – voir cet l’article).

Cette collecte de performances doit être faite à plusieurs occasions :

  • Avant tout mise en production : En utilisant les bons outils pour mener une campagne de simulation adéquate (en termes de nombre d’utilisateurs, de comportement utilisateur …). Aucune spéculation ne sera faite sur un test non représentatif (par ex: 1 serveur IIS/ASP.Net supporte 1 000 utilisateurs, donc 3 IIS/ASP.Net serveurs seront suffisants si on attend 3000 utilisateurs) … l’informatique n’est pas linéaire … et quid du reste de votre infrastructure : réseau, base(s) de données, autre(s) middleware(s) …
  • A l’issue de la campagne à la cible, on pourra même pousser l’application dans ses retranchements en injectant toujours plus d’utilisateurs afin de savoir quels composants/ressources fera défection en premier. Cela permettra d’anticiper un comportement face à un pic de charge inattendu (ou un attaque de type DDOS).
  • Une fois en production et sur un jour des plus standards, il convient de rejouer cette collecte de performances afin d’avoir des données « étalon » (« performance baseline »). Ce nous permettra de suivre la vie (et les perfomances) de notre application avec le temps et en fonction des évolutions (Changement d’OS/IIS, de framework de devéloppement, mise à jour de sécurité, P2V, Migration IaaS/PaaS, évolutions applicatives/fonctionnelles …). Le but étant de voir les gains (et d’éviter les pertes) que ces évolutions nous apportent.
  • Cette « performance baseline » évoluera (normalement dans le bon sens) avec le temps et devra être rafraichie à chaque évolution importante (applicative ou d’infrastructure) de votre application.

Je vous livre ci-dessous une liste de compteurs et même les lignes de commandes pour lancer la collecte pendant 24 heures de manière automatisée :

  • \.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(*)\*

Ligne de commandes :

REM To create a Data Collector Set with the appropriate Performance counters for an IIS server (every 15 seconds during 24 hours)
logman 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(*)\*" 
REM To start the Data Collector Set 
logman start %COMPUTERNAME%-IIS

Je laisse ici l’emplacement par défaut (%SYSTEMDRIVE%\PerfLogs\Admin\%COMPUTERNAME%-IIS) pour le fichier généré (*.blg) que vous pouvez bien entendu changer. Libre à vous de changer également la durée de la collecte (24 heures).

During my workshops and my customer visits, I often deal with the performance aspect and I note that many clients do not collect or do not know how to collect the right performance counters for IIS and ASP.Net. (A pre-analysis can be then done with PAL – see this article).

This performance collection must be done on several occasions:

  • Before putting the application in production: Using the right tools to lead an adequate benchmark test (in terms of number of users, user behavior …). No speculation will be made on a non-representative test (for example: 1 IIS / ASP.Net server supports 1000 users, so 3 IIS / ASP.Net servers will be sufficient if we expect 3000 users) … IT is not linear … and what about the rest of your infrastructure: network, database (s), other middleware (s) …
  • At the end of the benchmark test(s), we can even push the application to its limits by always injecting more and more users to know which components / resources will defect first. This will make it possible to anticipate behavior during an unexpected load peak (or a DDOS type attack).
  • Once in production and during a very standard day, it is necessary to replay this performance collection in order to have a « baseline performance ». This will allow us to follow the life (and performance) of our application over time and according to evolutions (OS / IIS change, development framework, security updates, P2V, IaaS / PaaS Migration, application / functional evolutions…). The goal is to see the gains (and avoid losses) that these evolutions bring us.
  • This performance baseline will evolve (normally in the right direction) over time and will have to be refreshed with each significant evolution (application or infrastructure) of your application.

I give you below a list of counters and even the command lines to start the collection for 24 hours in an automated way:

  • \.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(*)\*
 
REM To create a Data Collector Set with the appropriate Performance counters for an IIS server (every 15 seconds during 24 hours) 
logman 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(*)\*" 
REM To start the Data Collector Set 
logman start %COMPUTERNAME%-IIS

I keep here the default location (%SYSTEMDRIVE%\PerfLogs\Admin\%COMPUTERNAME%-IIS) for the generated file (* .blg) you can of course change. You are also free to change the duration of the collection (24 hours).

Laurent.

Feel free to share:)
Tweet
Étiqueté avec , , , ,