Sébastien Bovo [Microsoft France] : IIS

Plan d‘action pour la capture des informations lors d’un problème de production IIS

Sebastien Bovo — Wed, 13 May 2009 17:38:00 GMT

Je fais suite à mon précédent billet sur l’introduction sur le débogage en production afin de vous donner plus de précisions sur la collecte d’informations lors de l’apparition d’un problème en production.

Dans tous les cas se présentant à vous, je vous conseille de récupérer des serveurs Web les logs IIS, les logs HTTPErr et vos logs applicatifs. Vous trouverez les explications dans le billet Données à récolter pour un travail de surveillance ou d'investigation sur un serveur Web. Ces logs nous permettent de vérifier la charge utilisateur, les temps de réponses, les erreurs HTTP : ce sont des informations précieuses à relier avec le comportement observé de l’application. Aussi, si vous avez la possibilité de prendre un log Perfmon, cela constitue un apport d’informations supplémentaires.

D’un point de vue système, je résumerais les problématiques de production en deux comportements distincts :

Hang = Etat de blocage "deadlock" (avec ou sans 100% CPU) ou d’attente "hang" du processus
Crash = Arrêt "crash" du processus

La prise de dumps peut se faire par le script Adplus. Voici comment faire : Procédures de prises de dumps pour un serveur Web

D’une manière générale, vous pouvez utiliser Adplus pour les prises de dumps/logs pour tous les processus et pas pour IIS seulement. Les paramètres les plus utiles sont :

-p	–>	Spécifie le PID du processus
-pn	–>	Donne le nom du processus (plutôt que son PID)
-o	–>	Renseigne le répertoire de sortie pour la création du dumps

Ainsi, pour une prise de dumps de plusieurs processus et la création des dumps dans un répertoire particulier, la commande ressemble à

cscript.exe adplus.vbs -pn w3wp.exe -pn inetinfo.exe -crash -o c:\temp -quiet

Deux autres paramètres sont utiles :

-NoDumpOnFirst	–>	Permet de ne pas surcharger le débogueur (et donc le serveur) qui prend un mini dump pour chaque exception de première chance. Logue toutes les exceptions levées
-NoDumpOnSecond	–>	Aucune prise de dump mais seulement le remplissage d’un log permettant de visualiser toutes les exceptions levées

Pour vous donner plus de précisions, en deux mots, il existe deux types d'exceptions : première chance et seconde chance.

Une exception de première chance peut être interceptée par votre application par un try/catch ou un gestionnaire d’exceptions global
Si cette exception n’est pas gérée, elle est à nouveau levée mais comme une exception de seconde chance. Dans ce cas, seul un débogueur peut l’intercepter et si aucun débogueur n’est attaché, l’application se ferme (autrement dit : le processus crashe).

Par exemple, pour une prise d’un dump lors du crash de l’application "WpfApplication1.exe", vous pouvez utiliser "cscript.exe adplus.vbs -crash -pn WpfApplication1.exe -o c:\temp -quiet".

Cette commande a pour effet de brancher le débogueur "cdb.exe" au processus WpfApplication1.exe. Le debogueur logue toutes les exceptions dans un fichier pendant l’exécution du processus et si une exception de seconde chance est levée (provoquant l’arrêt du processus), un dump est pris.

Le répertoire de sortie contient les fichiers suivants :

Process_List.txt - Liste des processus s’éxécutant sur la machine au moment du lancement de la commande
un ou plusieurs fichiers du type PID-2852__WPFAPPLICATION1.EXE__Date_05-13-2009__Time_15-46-0303.log - Log des exceptions levées par l’application
un ou plusieurs fichiers du type PID-2852__WPFAPPLICATION1.EXE__2nd_chance_NET_CLR__full_0a70_2009-05-13_15-46-10-421_0b24.dmp - Dump du processus

A noter que le répertoire et les fichiers contiennent la date et l’heure exacte de la prise de dumps. Dans l’exemple précédent, il s’agit du 2009-05-13 pour le 13 mai et 15-46-10 pour 15h46m.

Nous avons donc maintenant toutes les données nécessaires (en particulier les dumps) pour déboguer à tête reposée. Ouvrons le dump avec Windbg :-)

Sebastien.

>>> Suite : Premiers pas avec WinDbg

Gestion des versions des assemblies du GAC par ASP.NET

Sebastien Bovo — Thu, 30 Apr 2009 09:36:00 GMT

Le GAC nous permet de partager des assemblies entre plusieurs applications ASP.NET. La gestion des versions des ces assemblies en est aussi facilitée à condition de bien comprendre la différence entre Assembly version et File version.

Allez hop... Petite explication !

Lors de la mise à jour d’une assembly nous avons le choix entre changer l’Assembly version et la File version

Pour illustrer les deux possibilités, prenons l’exemple de plusieurs sites Web utilisant une même assembly dans le GAC (Assembly V1.0.0.0 / File V1.0.0.0). Les Web.config des applications ASP.NET utilisent :

Possibilité 1 : Modification mineure = Correctif

Nous mettons à jour cette assembly dans la GAC en gardant la même Assembly version mais en changeant la File version (Assembly V1.0.0.0 / File V1.1.0.0)

Dans la GAC, nous avons maintenant seulement la nouvelle assembly (Assembly V1.0.0.0 / File V1.1.0.0). Cette nouvelle assembly remplace la précédente car nous avons la même Assembly version. En effet, dans la GAC, deux assemblies du même nom ne peuvent pas avoir la même Assembly version
Les applications en cours d’exécution utilisent toujours la version précédente (Assembly V1.0.0.0 / File V1.0.0.0) car pour elles rien ne leur indique un changement (le web.config n’a pas changé)
Si l’appDomain redémarre : c'est-à-dire si l’application Web redémarre suite à une modification du Web.config par exemple, la nouvelle version n’est toujours pas chargée car l’ancienne est en mémoire dans le processus W3WP.EXE qui n’a pas redémarré
Si le processus W3WP.EXE redémarre suite à un recyclage, un crash, alors la CLR va chercher dans le GAC la dll et prend la nouvelle version

Possibilité 2 : Modification majeure = Nouvelle version

Nous mettons à jour cette assembly dans la GAC en changeant le numéro de l’Assembly version (Assembly V2.0.0.0)

Dans la GAC, nous voyons maintenant les deux assemblies

Les applications en cours d’exécution utiliseront toujours l’Assembly version 1.0.0.0 tant que le web.config n’est pas modifié pour mentionner le changement de version :

Comme modifions le Web.config, l’appDomain redémarre (sans redémarrage du processus W3WP.EXE) et prend en charge la nouvelle version

Conclusion en images :-)

Changement File version
Redémarrage W3WP.EXE	Prise en compte de la nouvelle version
Modification Web.config	Aucun changement

Changement Assembly version
Redémarrage W3WP.EXE	Aucun changement
Modification Web.config	Prise en compte de la nouvelle version

J’espère que ces éclaircissements vous aideront dans vos déploiements en production. A bientôt,

Sebastien.

Utilisez TinyGet pour effectuer rapidement une charge simple sur un serveur Web

Sebastien Bovo — Fri, 10 Apr 2009 12:04:00 GMT

L’outil TinyGet n’a pas vocation remplacer un outil de test de charge blogs.mais il s’avère extrêmement pratique dans certains cas : Je vous conseille de le garder dans vos outils favoris. Il vous permettra de simuler une charge basique sur une application Web en quelques lignes de commandes.

Les avantages sont les suivants :

Support du multithread pour effectuer des requêtes simultanées
Support des itérations
Paramétrage possible pour le type authentification, la version HTTP, les headers, le contenu de la requête, l’utilisation d’un certificat client
Attente d’un contenu particulier pour la réponse, le code de retour

Exemple de trois threads simultanés effectuant dix requêtes chacun

tinyget.exe -srv:sbovo02 -uri:/default.aspx -status:200 -threads:3 -loop:10

-threads donne le nombre de threads lancés simultanément.

-loop indique le nombre d’itérations

-status représente le code de retour attendu. Si TinyGet n’obtient pas ce code, un message est affiché dans la console

Exemple d’une requête attendant un contenu particulier

tinyget.exe -srv:sbovo02 -uri:/contenu.aspx -testContainString:"Texte"

-testContainString permet de mentionner quelle chaine (contenu dans le body de la réponse) nous attendons

Exemple d’une requête avec l’affichage de la trace TinyGet ou les headers de la réponse

tinyget.exe -srv:sbovo02 -uri:/stylesheet.css -trace

tinyget.exe -srv:sbovo02 -uri:/stylesheet.css -headers

Pour télécharger l’outil et l’aide associée : IIS 6.0 Resource Kit Tools - http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1352

Je pense que vous avez bien vu l’utilité de cet outil soit pour simuler une charge soit pour vérifier les réponses d’une application Web.

Bonne utilisation !

Sebastien.

Utilisation de Logparser pour les logs IIS : Status code, erreurs 404, erreurs 500, fréquentation

Sebastien Bovo — Mon, 16 Mar 2009 16:25:00 GMT

Bonjour,

Voici quelques requêtes Logparser utiles pour la surveillance d’un serveur Web.

Bonne utilisation,

Sebastien.

Pourcentage des codes de retour

StatusCode.sql

SELECT
    sc-status as Statut,
    COUNT(*) as NbRequetes,
    MUL(PROPCOUNT(*),100) as %
FROM
    ex\*.log
GROUP BY
    sc-status

A partir des données de sortie, vous pouvez facilement créer un graphique (cf. ci-dessous) avec un copier/coller dans Excel par exemple.

Erreurs 404 - Fichiers inexistants

Url404.sql

SELECT
    cs-uri-stem as Url,
    COUNT(*) as NbRequetes
FROM
    ex\*.log
WHERE
    sc-status = 404
GROUP BY
    cs-uri-stem

Ce type de requête permet d’identifier les pages/fichiers/images n’existant pas, bien qu’étant toujours référencés par des pages de l’application. Vous pouvez aussi repérer par ce biais, les urls mal orthographiées.

Erreurs 500 - Erreurs ASP.NET

Url500.sql

SELECT
    cs-uri-stem as Url,
    COUNT(*) as NbRequetes
FROM
    ex\*.log
WHERE
    sc-status = 500
GROUP BY
    cs-uri-stem

Le but est de pouvoir rapidement vérifier si une url/page est la source d’une grande partie des erreurs du site Web.

Url500Completes.sql

SELECT
    cs-method as Methode,
    UrlComplete,
    sc-substatus as SousStatut,
    sc-win32-status as Win32Statut
USING
    STRCAT(cs-uri-stem,
        REPLACE_IF_NOT_NULL(cs-uri-query, STRCAT('?', cs-uri-query))) as UrlComplete
FROM
    ex\*.log
WHERE
    sc-status = 500

En ajoutant, les informations sur le verbe HTTP et la querystring, il est possible de commencer les investigations.

Fréquentation - Nombre de requêtes par heure

NbRequetesParHeure.sql

SELECT
    TO_LOCALTIME(QUANTIZE(time,3600)) AS Heure,
    COUNT(*) AS NbRequetes
FROM
    ex\*.log
GROUP BY
    Heure
ORDER BY
    Heure ASC

Cette requête est intéressante car elle utilise la fonction "QUANTIZE" qui permet dans ce cas, de regrouper tous les accès par tranches de 3600s (1h). Cela nous permet de visualiser l’évolution de la fréquentation du site Web.

Comme décrit dans mon précédent post, pour utiliser ces requêtes, il vous suffit de lancer le fichier "LancerLogParserSurLogsIIS.cmd" avec le nom du fichier .sql en entrée et le nom du fichier .txt en sortie. Par exemple :

LancerLogParserSurLogsIIS.cmd Url404.sql Url404.txt

Pour rappel, le fichier LancerLogParserSurLogsIIS.cmd est :

Logparser.exe file:%1 -i:IISW3C -o:TSV > %2

Analyse des fichiers de logs avec LogParser

Sebastien Bovo — Tue, 13 Jan 2009 16:53:19 GMT

Bonjour à tous,

Savez-vous que Microsoft fournit un outil très puissant pour traiter tous les fichiers logs, même les siens :-) ?

Cette outil s’appelle "LogParser" et se présente sous deux formes :

Un exécutable (x1) utilisable (x2) et automatisable (x3) en ligne de commandes
Une dll COM que l’on peut référencer dans nos projets pour développer une solution profitant des fonctionnalités de l’outil

Les possibilités et les scénarios d’utilisation sont vraiment nombreux. En plus, l’outil est impressionnant de rapidité !

En deux mots, le moteur de LogParser prend en entrée plusieurs formats comme les fichiers texte, les journaux d’évènements, ou bien directement le système de fichiers ou encore l’active Directory. Concernant les fichiers plats, il n'y a pas de restriction : les fichiers de logs avec les séparateurs habituels (point virgule, virgule, tabulation, etc...) sont pris en charge.

Nous manipulons dans la requête directement le nom des champs (par exemple : "sc-status", "time-taken", etc...).

Le moteur de LogParser permet d’éxécuter une requête de type SQL pour filtrer, ordonner, consolider les données et en sortir les résultats sous différentes formes. Il est même possible de faire directement l'insertion des données dans une base SQL Server ou de générer des graphiques.

Pour simplifier l'utilisation de l'outil en ligne de commande, vous pouvez créer un fichier cmd prenant en entrée le fichier contenant le requête SQL et le nom du fichier de sortie :

LancerLogParserSurLogsIIS.cmd

Logparser.exe file:%1 -i:IISW3C -o:TSV > %2

En exemple, voici une requête donnant les moyennes du temps total d'exécution des requêtes faites sur un site Web :

TempsExecutionMoyen.sql

SELECT AVG(time-taken) as TempsExecutionMoyen, COUNT(*) as PourNbRequetes, cs-uri-stem as Url
FROM ex\*.log
WHERE
    (cs-uri-stem not like '%.gif')
    and (cs-uri-stem not like '%.css')
    and (cs-uri-stem not like '%.js')
    and (cs-uri-stem not like '%.jpg')
GROUP BY
    Url
ORDER BY
    TempsExecutionMoyen DESC

Il suffit ensuite de lancer le fichier cmd :

LancerLogParserSurLogsIIS.cmd TempsExecutionMoyen.sql TempsExecutionMoyen.txt

Le résultat est sous la forme suivante (fichier avec séparation par tabulation) :

TempsExecutionMoyen    PourNbRequetes    Url
67843    8    /monapp/AllProducts.aspx
5532    9    /monapp/CreateAccount.aspx
5525    3    /monapp/FeaturedProducts.aspx
5062    8    /monapp/CompanyInformation.aspx
2261    4    /monapp/Links.aspx
305    28    /monapp/ProductInfo.aspx
156    1    /monapp/
61    9    /monapp/Reviews.aspx
56    5    /monapp/News.aspx
0    4    /monapp/Default.htm

Statistics:
-----------
Elements processed: 203
Elements output: 10
Execution time: 0.01 seconds

Le plus intéressant est que ce fichier peut être directement ouvert dans Excel afin de pouvoir profiter du filtre automatique, de la création de graphiques : L'analyse en devient presque facile !

L'outil est disponible à l'adresse suivante - http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en

A utiliser sans modération :-)

Sebastien.

Paramétrages initiaux des pools d'applications IIS6

Sebastien Bovo — Tue, 02 Dec 2008 14:53:00 GMT

Voici quelques recommandations/explications qui pourront vous aider lors du paramétrage initial (manuel ou automatisé) de vos pools d'applications ASP.NET sur vos serveurs IIS6.

Pool d'applications et worker process

Un pool d’application correspond à un processus W3WP.EXE (ou plusieurs, si WebGarden est différent de 1). Il est possible de n’avoir qu’une seule version du .NET Framework chargée dans un processus.

Dans le cas où vous auriez plusieurs applications ou plusieurs sites Web,

Vous devez faire attention à ce que les sites Web/répertoires virtuels qui sont affectés à un pool d’applications, utilisent la même version du .NET Framework
De plus, afin de faire une séparation des applications en plusieurs pools d’applications, vous devez tenir compte :
- De la mémoire physique totale du serveur. En effet, chaque processus peut utiliser jusqu'à 1Go-1,5Go de mémoire virtuelle (rarement plus à cause de la fragmentation mémoire même si la limite théorique est de 2Go)
- Du nombre d’applications et de leur empreinte mémoire respectives
Des résultats des tests de charge. En effet, si d’après les tests vous vous apercevez qu’une application consomme beaucoup de mémoire ou crashe régulièrement, cela fait sens de l’isoler dans un pool d’applications afin d’investiguer

Paramètres des pools d'applications

Premier point : il est conseillé d’enlever l’option « Recycle worker processes (in minutes) ». En effet, ce paramètre n’est pas adapté à la production dans la mesure où le recyclage peut se faire à n’importe quel moment de la journée.

Par contre, si vous le jugez utile, vous pouvez planifier un recyclage journalier pendant un une plage horaire où l’application n’est pas utilisée. Cela permet de relancer un nouveau processus W3WP.EXE et de repartir à zéro concernant la charge mémoire. Par contre, lors de la première connexion du premier utilisateur de la journée, l’application se chargera dans le W3WP.EXE. Ce chargement sera sensible au niveau des performances. Il est possible de ne pas subir cette baisse de performances au démarrage de l’application en simulant plusieurs accès au site Web (par un outil, par script) avant que le premier utilisateur se connecte. Je vous conseille aussi d'utiliser la précompilation ASP.NET.

Si une application possède une fuite mémoire, vous pouvez l’isoler dans un pool d’applications. Il est possible d’utiliser les options de « Memory recycling » ou un recyclage planifié toutes les nuits. Sachez que lorsqu’il y a un recyclage et que si l’application utilise le mode de session dit « InProc » (dans le Web.config), vous perdez les variables de l'application et de sessions.

Le recyclage par seuil de mémoire peut se faire en fonction de :

- « Maximum used memory » ce qui correspond à la taille réelle du processus en mémoire

- « Maximum virtual memory » ce qui correspond à la taille de la mémoire virtuelle adressée par le processus

Le champ « Idle timeout » donne le nombre de minutes, après le dernier accès à l’application, au bout duquel le W3WP.EXE se décharge de la mémoire. Le but est d’économiser les ressources du serveur lorsque celui-ci n’est pas utilisé.

Le champ « Request queue limit » correspond à la taille de la file d’attente kernel utilisée pour les requêtes http entrantes destinées aux applications exécutées dans le pool d’applications.

Le champ « Enable pinging » indique le nombre de secondes entre chaque vérification de présence/bon fonctionnement du W3WP.EXE. Dans le cas où le processus ne répond pas, IIS en redémarre un nouveau afin de garantir la disponibilité du serveur Web.

Le champ « Enable rapid-fail protection » est le mécanisme inverse : si l’application est dangereuse pour la santé du serveur, le pool d’application est désactivé. Une action de l’administrateur est nécessaire pour le réactiver.

« Startup time limit » et « Shutdown time limit » correspondent au temps maximum que nous donnons à IIS pour, respectivement, démarrer/arrêter le W3WP.EXE. Si le processus ne démarre pas ou ne s’arrête pas dans le temps imparti. IIS fait un nouvel essai de démarrage/arrêt avec un nouveau processus.

Données à récolter pour un travail de surveillance ou d'investigation sur un serveur Web

Sebastien Bovo — Wed, 26 Nov 2008 10:35:00 GMT

Afin de commencer un travail d’investigation sur le fonctionnement d’une application Web (erreurs, crashes, performance, fuites mémoire), les données les intéressantes à récupérer d’un serveur Web sont :

- Logs IIS

- Logs HTTPERR

- Journaux d’événements

- Logs perfmon si possible

- Dumps si necessaire

Voici plus de précisions :

Logs IIS

Les logs IIS sont les fichiers contenus dans « C:\windows\system32\logfiles\W3SVCxxxx ». xxxx représente le numéro du site Web.

Vous avez ensuite un ou plusieurs fichiers portant la date du jour

Référence pour les codes IIS :

Description of Microsoft Internet Information Services (IIS) 5.0 and 6.0 status codes - http://support.microsoft.com/kb/318380/en-us

Logs HTTPERR

Il s'agit des logs de la partie Kernel de Windows qui réceptionne les requêtes et envoie les réponses.

Pour analyser les messages d'erreurs contenus dans ces logs :

Error logging in HTTP API - http://support.microsoft.com/kb/820729/en-us

Les journaux d’évènements Application, Système et Sécurité

Les journaux donnent des informations pertinentes sur les redemarrages d'IIS/des pools d'applications, sur erreurs remontés par les pools d'applications, etc...

WWW Service Events (IIS 6.0) - http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ea584d51-16b5-4be7-9e70-7c7487ca4500.mspx?mfr=true
WWW Service Worker Process Events (IIS 6.0) - http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ea584d51-16b5-4be7-9e70-7c7487ca4500.mspx?mfr=true

Deux précisions sur les logs IIS :

- Pour apprécier le temps total de traitement des requêtes par le serveur Web, nous vous conseillons d’activer le champ « time-taken » des logs IIS6. Ce champs donne le temps total de traitement de chaque requête à partir du moment où le serveur reçoit la requête jusqu’au moment où il renvoie la réponse HTTP. Cela englobe le temps de traitement Web Service et/ou Base de données sous-jacent.

- Le Win32 Status peut être aussi très utile. Il est possible d’en connaitre la signification avec l’outil « Err.exe » : Microsoft Exchange Server Error Code Look-up - Err.exe

Procédures de prises de dumps pour un serveur Web

Sebastien Bovo — Tue, 25 Nov 2008 10:50:00 GMT

Voici une procédure simple pour effectuer une prise de dumps sur IIS.

Utilisation d’ADPLUS.VBS

L’outil de prise de dumps est "adplus". Il est fourni avec les outils de débogage Windows téléchargeables à l’adresse - http://www.microsoft.com/whdc/devtools/debugging/.

La démarche d’installation que je vous conseille est la suivante :

- Télécharger les outils de débogage

- Faire l’installation sur une machine quelconque

- Copier sur le serveur Web le répertoire qui a été installé par les outils de débogage (par exemple dans « C:\debuggers\ »)

Prise d’un dump automatiquement lors d’un crash

Ouvrir une session avec un compte administrateur sur le serveur Web (se connecter avec « /console » si vous utilisez Terminal Serveur)
En ligne de commande, naviguer vers le répertoire contenant les outils de débogage
Lancer la commande suivante : « cscript.exe adplus.vbs -iis -crash -quiet ». A partir de ce moment, un débogueur est branché sur les processus IIS et prend un dump si un crash apparait
Récupérer le répertoire nommée de la façon suivante « Crash_Mode__Date_01-11-2007__Time_18-31-1515 »

Si vous avez beaucoup de mini-dumps, vous pouvez utiliser « cscript.exe adplus.vbs -iis -crash –quiet -nodumponfirst » pour avoir seulement un dump de second chance.

Prise d’un dump au moment du lancement de la commande

Pour une prise d’un dump immédiatement, dans le cas ou vous vous apercevez d’un problème ponctuel (application ne répondant pas, ayant de très mauvaises performances) ou dans le cas d’une fuite mémoire, la commande est « cscript.exe adplus.vbs -iis -hang -quiet » :

Ouvrir une session avec un compte administrateur sur le serveur Web (se connecter avec « /console » si vous utilisez Terminal Serveur)
En ligne de commande, naviguer vers le répertoire contenant les outils de débogage
Lancer la commande suivante : « cscript.exe adplus.vbs -iis -hang -quiet ». Les dumps des processus IIS sont pris immédiatement
Récupérer le répertoire nommée de la façon suivante « Hang_Mode__Date_01-11-2007__Time_18-31-1515 »

L’analyse des dumps se fait avec l’outil WinDbg (fourni avec les outils de débogage Windows) par vous et/ou par le support Microsoft.

Performances de vos applications ASP.NET - Quels compteurs étudier ?

Sebastien Bovo — Fri, 31 Oct 2008 15:15:42 GMT

Les compteurs de performance sont très nombreux et l’on peut rapidement s’y perdre ou perdre son temps à tous vouloir les utiliser. Pour être le plus productif possible, je vous propose par expérience, une liste de compteurs. Vous pouvez les étudier en tout premier lieu lors de vos tests de charges. Ensuite, en fonction des résultats, vous jugerez utile d’en ajouter d’autres plus ciblés.

Voici donc une liste qui peut vous servir de point de départ :

.NET CLR Exceptions
- # of Exceps Thrown/sec <<W3WP.EXE>>
.NET CLR Memory
- # Bytes in all Heaps <<W3WP.EXE>>
- % Time in GC
- Large Object Heap size <<W3WP.EXE>>
ASP.NET V2
- Requests Current
- Worker Process Restarts
ASP.NET Apps V2
- Errors Total/sec
- Request Execution Time
- Requests/sec
Processor
- % Processsor Time _Total
Process
- % Processsor Time <<W3WP.EXE>>
- Virtual Bytes <<W3WP.EXE>>
- Private Bytes <<W3WP.EXE>>
Web Service
- Anonymous Users/sec <<NomSiteWeb>>
- Get Requests/sec <<NomSiteWeb>>
- Post Requests/sec <<NomSiteWeb>>

Pour référence, je vous conseille les deux chapitres du guide "Improving .NET Application Performance and Scalability"

Chapter 15 — Measuring .NET Application Performance - http://msdn.microsoft.com/en-us/library/ms998579.aspx
Chapter 17 — Tuning .NET Application Performance - http://msdn.microsoft.com/en-us/library/ms998583.aspx

Aussi, voici un point d'entrée tres interessant sur les meilleures pratiques et l'optimisation des performances

Performance Overview - http://msdn.microsoft.com/en-us/library/cc668225.aspx

Par exemple, pour l'analyse des courbes obtenues, si vous regardez l’utilisation mémoire, l’important est de surveiller avant tout les compteurs "Process - Virtual Bytes <<W3WP.EXE>>" et "Process - Private Bytes <<W3WP.EXE>>" :

Les "Virtual Bytes" d’un processus correspondent à la mémoire réservée par ce processus. Elle est de deux types : "Reserved" et "Committed". Dans le premier cas, la mémoire n'est plus libre mais pas encore utilisée : le processus se réserve le droit d'y placer des données. La mémoire "Committed" est allouée et utilisée : elle est pris sur la mémoire physique du serveur.
Les "Private Bytes" d'un processus représentent la mémoire réellement utilisée et prise sur la mémoire physique. Autrement dit : il s'agit la partie "Committed" des "Virtual Bytes"

Par conséquent, si un de ces deux compteurs est en constante augmentation sans jamais redescendre, vous avez une fuite mémoire. Dans ce cas, d'autres compteurs pourront vous aider. Par exemple :

".NET CLR Memory - # Bytes in all Heaps <<W3WP.EXE>>" donne la taille mémoire utilisée par tous les objets .NET contenus dans le processus W3WP.EXE sélectionné. Si ce compteur augmente aussi de la même manière, la fuite mémoire est provoquée par les objets managés utilisés
"Large Object Heap size <<W3WP.EXE>>" comprend seulement les objets .NET dits volumineux (supérieurs à 85 ko). La mémoire utilisée par ces objets est particulière parce qu'elle n'est pas compactée/optimisée lors du passage du garbage collector. Son utilisation intensive peut provoquer de la fragmentation mémoire

Bon tests ou surveillances de vos applications ASP.NET :-)

A bientôt,

Sebastien.