Partager via

analyse des performances ASP.NET et quand alerter les administrateurs

  • Article

 

Thomas Marquardt
Microsoft Corporation

Mise à jour de juillet 2003

S’applique à :
   Microsoft® ASP.NET

Résumé: Décrit les compteurs de performances les plus utiles pour diagnostiquer les problèmes de stress et de performances dans les applications Microsoft ASP.NET, les seuils à définir pour alerter les administrateurs en cas de problèmes et d’autres ressources qui peuvent être utilisées pour surveiller l’intégrité d’une application ASP.NET. (17 pages imprimées)

Téléchargez le code source de cet article.

Contents

Surveillance des compteurs de performances
Analyse du journal des événements
Surveillance des journaux W3C et HTTPERR
Autres ressources utilisées pour surveiller les ASP.NET
Présentation des compteurs de performances
   Compteur d’exceptions CLR .NET
   Compteurs de chargement CLR .NET
   Compteurs de mémoire CLR .NET
   compteurs ASP.NET
   compteurs d’applications ASP.NET
   Compteurs de processus
   Compteur de processeur
   Compteur de mémoire
   Compteur système
   Compteurs de service web
Conclusion

Surveillance des compteurs de performances

De nombreux compteurs de performances sont disponibles pour l’analyse des applications. Choisir ceux à inclure dans les journaux de performances peut être difficile, et apprendre à les interpréter est un art. Cet article devrait vous aider à vous sentir plus à l’aise avec ces deux tâches.

Au minimum, les compteurs de performances suivants doivent être surveillés pour les applications Microsoft® ASP.NET :

  • Processeur(_Total)\% de temps processeur
  • Process(aspnet_wp)\% Processor Time
  • Process(aspnet_wp)\Private Bytes
  • Process(aspnet_wp)\Virtual Bytes
  • Process(aspnet_wp)\Handle Count
  • Exceptions CLR Microsoft® .NET\# Exceps levées/s
  • ASP.NET\Redémarrages d’application
  • ASP.NET\Demandes rejetées
  • ASP.NET\Worker Process Restarts (non applicable à IIS 6.0)
  • Mémoire\\Mégaoctets disponibles
  • Service web\Connexions actuelles
  • Service web\Demandes d’extension ISAPI/s

Vous trouverez ci-dessous une liste plus large de compteurs de performances utiles pour l’analyse des performances. Il est toujours bon d’avoir plus de données de performances que pas assez, en particulier lorsque vous rencontrez un problème qui n’est pas facilement reproduit. La liste omet plusieurs compteurs de performances qui ne sont généralement pas nécessaires. Par exemple, l’état de session et les compteurs de performances des transactions ne sont nécessaires que lorsque les fonctionnalités sont utilisées.

Quelques seuils sont recommandés en fonction de mon expérience du débogage et du test ASP.NET applications. Vous pouvez rechercher « Seuil » dans cet article pour y accéder directement. Les administrateurs doivent déterminer s’ils doivent déclencher des alertes lorsque ces seuils sont dépassés en fonction de leur expérience. Dans la plupart des cas, les alertes sont appropriées, en particulier si le seuil est dépassé pendant des périodes prolongées.

Analyse du journal des événements

Il est essentiel de surveiller le journal des événements pour les messages provenant de ASP.NET et de Microsoft® Internet Information Server (IIS). ASP.NET écrit des messages dans le journal de l’application, par exemple, chaque fois que le processus de travail aspnet_wp s’arrête. IIS 6.0 écrit des messages dans les journaux d’activité de l’application et/ou du système, par exemple, chaque fois que le processus de travail w3wp se signale ou se bloque. Il est assez facile d’écrire une application .NET qui lit le journal des applications et filtre les messages de ASP.NET et IIS, et déclenche une alerte (envoie un courrier électronique ou compose un radiomessagerie) si nécessaire.

Surveillance des journaux W3C et HTTPERR

Tout d’abord, activez la journalisation W3C pour IIS 5.0 et IIS 6.0 via le Gestionnaire des services Internet (IIS). Ce journal peut être configuré pour inclure diverses données sur les requêtes, telles que l’URI, le code status, etc. Analysez le journal à la recherche de codes d’erreur tels que 404 Introuvable et prenez des mesures pour corriger les liens, si nécessaire. Sur IIS 6.0, le code de sous-état est inclus dans le journal et est utile pour le débogage. IIS utilise des codes de sous-état pour identifier des problèmes spécifiques. Par exemple, 404.2 indique que l’extension ISAPI qui gère la requête est verrouillée. Vous trouverez la liste des codes de status et de sous-état dans la rubrique À propos des messages d’erreur personnalisés.

Nouveauté d’IIS 6.0, les requêtes et requêtes incorrectes ou incorrectes qui ne peuvent pas être traitées par un pool d’applications sont enregistrées dans le journal HTTPERR par HTTP.SYS, le pilote en mode noyau pour la gestion des requêtes HTTP. Chaque entrée inclut l’URL et une brève description de l’erreur.

Vérifiez le journal HTTPERR pour les demandes rejetées. Les demandes sont rejetées par HTTP.SYS lorsque la file d’attente des demandes du noyau est dépassée et lorsque l’application est mise hors connexion par la fonctionnalité Protection rapide contre les défaillances. Lorsque le premier problème se produit, l’URL est enregistrée avec le message QueueFull, et lorsque le second se produit, le message est AppOffline. Par défaut, la file d’attente des requêtes du noyau est définie sur 1 000 et peut être configurée dans la page Propriétés du pool d’applications du Gestionnaire des services Internet. Je vous recommande d’augmenter ce nombre à 5 000 pour un site occupé, car la file d’attente de requêtes du noyau peut facilement dépasser 1 000 si un pool d’applications se bloque alors qu’un site est soumis à une charge très élevée.

Vérifiez dans le journal HTTPERR les demandes perdues en raison d’un blocage ou d’un blocage du processus de travail. Lorsque cela se produit, l’URL est journalisée avec le message , Connection_Abandoned_By_AppPool, pour chaque demande en cours. Une demande en cours est une demande qui a été envoyée à un processus de travail pour traitement, mais qui n’a pas été effectuée avant l’incident ou le blocage.

Pour plus d’informations sur le journal HTTPERR, consultez l’article de la Base de connaissances Microsoft 820729 : INFO : Journalisation des erreurs dans l’API HTTP.

Autres ressources utilisées pour surveiller les ASP.NET

Les compteurs de performances et les journaux des événements n’interceptent pas toutes les erreurs qui se produisent et ne sont donc pas tout à fait suffisants pour surveiller ASP.NET. Je vous recommande d’écrire une application simple qui envoie une requête HTTP pour une ou plusieurs pages et attend une certaine réponse. Cet outil doit surveiller l’heure du dernier octet (TTLB) pour s’assurer que les pages sont servies en temps opportun. Il doit également enregistrer toutes les erreurs qui se produisent, car ces informations seront nécessaires pour analyser le problème.

Le kit de ressources IIS 6.0 inclut Log Parser 2.1, un outil permettant d’analyser les fichiers journaux (journal W3C, journal HTTPERR, journaux des événements) et de stocker les résultats dans un fichier ou une base de données. Le kit de ressources peut être installé sur Microsoft® Windows® XP et Microsoft® Windows Server™ 2003.

Vous pouvez également écrire une application qui collecte des données de performances, filtre le journal des événements et enregistre les données clés dans une base de données Microsoft® SQL Server. Il est étonnamment facile de le faire à l’aide de l’espace de noms System.Diagnostics . Vous pouvez même surveiller les redémarrages de processus de travail à l’aide de la classe System.Diagnostics.Process .

Pour vous aider à démarrer, utilisez le lien en haut de cet article pour télécharger l’exemple de code pour plusieurs outils utiles :

  1. Code source pour snap.exe, un outil en ligne de commande pour la journalisation des données de performances pour les processus. Le fichier Snap.cs contient une brève description et explique comment compiler l’outil.
  2. Code source pour HttpClient.exe, un client simple qui enregistre l’heure du dernier octet (TTLB) pour les requêtes HTTP. Le fichier HttpClient.cs contient une brève description et explique comment compiler l’outil.
  3. Code source pour qqq.exe, outil en ligne de commande permettant de tester les contraintes d’une application ASP.NET. Lorsqu’il est utilisé en association avec un client stress, tel que Microsoft® Application Center Test (ACT), cet outil attache des débogueurs au processus de travail et surveille certains compteurs de performances. Il peut être paramétré pour s’introduire dans les débogueurs lorsque les performances se dégradent. Le fichier qqq.cs contient une description précise et explique comment compiler l’outil.
  4. La page pminfo.aspx utilise la classe System.Web.ProcessModelInfo pour afficher des informations sur les redémarrages de processus de aspnet_wp. L’historique est conservé jusqu’à ce que le service w3svc soit arrêté.
  5. Code source pour ErrorHandler.dll. Il s’agit d’un IHttpModule que vous pouvez ajouter au pipeline HTTP pour journaliser les exceptions non gérées dans le journal des événements. Il est préférable de consigner les erreurs dans une base de données SQL Server, mais l’exemple utilise le journal des événements par souci de simplicité.

Une autre étape simple consiste à implémenter Application_Error. Vous pouvez ajouter le texte suivant à global.asax et commencer immédiatement à journaliser la plupart des erreurs non gérées dans le journal des applications :

<%@ import namespace="System.Diagnostics" %>
<%@ import namespace="System.Text" %>

const string sourceName      = ".NET Runtime";
const string serverName      = ".";
const string logName         = "Application";
const string uriFormat       = "\r\n\r\nURI: {0}\r\n\r\n";
const string exceptionFormat = "{0}: \"{1}\"\r\n{2}\r\n\r\n";

void Application_Error(Object sender, EventArgs ea) {
    StringBuilder message = new StringBuilder();
    
    if (Request != null) {
        message.AppendFormat(uriFormat, Request.Path);
    }
  
    if (Server != null) {
        Exception e;
        for (e = Server.GetLastError(); e != null; e = e.InnerException) {
            message.AppendFormat(exceptionFormat, 
                                 e.GetType().Name, 
                                 e.Message,
                                 e.StackTrace);
        }
    }

    if (!EventLog.SourceExists(sourceName)) {
        EventLog.CreateEventSource(sourceName, logName);
    }

    EventLog Log = new EventLog(logName, serverName, sourceName);
    Log.WriteEntry(message.ToString(), EventLogEntryType.Error);

    //Server.ClearError(); // uncomment this to cancel the error
}

Application_Error intercepte les erreurs d’analyseur, de compilation et d’exécution dans les pages. Il n’interceptera pas les problèmes de configuration, ni les erreurs qui se produisent dans inetinfo pendant que aspnet_isapi traite la demande. En outre, lors de l’utilisation de l’emprunt d’identité, le jeton impersonné doit avoir l’autorisation d’écrire dans cette source d’événement. Vous pouvez éviter le problème lié à l’emprunt d’identité en journalisant les erreurs dans une base de données SQL Server.

Enfin, les outils de débogage Microsoft® pour Windows sont très utiles pour le débogage des problèmes sur un serveur web de production. Ces outils peuvent être téléchargés à partir de https://www.microsoft.com/whdc/ddk/debugging/installx86.mspx. Il existe une extension de débogueur nommée sos.dll que vous pouvez charger dans le débogueur windbg.exe ou cdb.exe pour déboguer du code managé. Il peut vider le contenu du tas de garbage collection (GC), afficher les traces de pile managées, faciliter l’examen des conflits pour les verrous managés, afficher les statistiques du pool de threads et bien plus encore. Il peut être téléchargé dans le cadre de l’ensemble d’outils de débogage mentionné dans Débogage de production pour les applications .NET Framework.

Présentation des compteurs de performances

Voici une brève description des compteurs de performances importants et de leur utilisation.

Compteur d’exceptions CLR .NET

Le compteur _Global_ instance ne doit pas être utilisé avec ce compteur, car il est mis à jour par tous les processus managés. Utilisez plutôt le aspnet_wp instance.

  • #Exceps levée /s. Nombre total d’exceptions managées levées par seconde. À mesure que ce nombre augmente, les performances se dégradent. Les exceptions ne doivent pas être levées dans le cadre d’un traitement normal. Notez toutefois que Response.Redirect, Server.Transfer et Response.End entraînent tous la levée d’une exception ThreadAbortException plusieurs fois, et qu’un site qui s’appuie fortement sur ces méthodes entraîne une pénalité de performances. Si vous devez utiliser Response.Redirect, appelez Response.Redirect(url, false), qui n’appelle pas Response.End et ne lève donc pas. L’inconvénient est que le code utilisateur qui suit l’appel à Response.Redirect(url, false) s’exécute. Il est également possible d’utiliser une page HTML statique pour rediriger. L’article de la Base de connaissances Microsoft 312629 fournit des détails supplémentaires.

    En plus de surveiller ce compteur de performances très utile, l’événement Application_Error doit être utilisé afin d’alerter les administrateurs en cas de problèmes.

    Seuil : 5 % de RPS. Les valeurs supérieures doivent être examinées et un nouveau seuil doit être défini si nécessaire.

Compteurs de chargement .NET CLR

Le compteur _Global_ instance ne doit pas être utilisé avec ces compteurs de performances, car il est mis à jour par tous les processus managés. Utilisez plutôt le aspnet_wp instance.

  • AppDomains actuels. Nombre actuel d’AppDomains chargés dans le processus. La valeur de ce compteur doit être identique au nombre d’applications web plus 1. AppDomain supplémentaire est le domaine par défaut.

  • Assemblys actuels. Nombre actuel d’assemblys chargés dans le processus. Par défaut, les fichiers ASPX et ASCX d’un répertoire sont compilés par lots. Cela génère généralement un à trois assemblys, en fonction des dépendances. Par exemple, s’il existe des pages ASPX avec des dépendances au moment de l’analyse des fichiers ASCX, deux assemblys sont généralement générés. L’un contiendra les fichiers ASPX, les autres fichiers ASCX. Les dépendances au moment de l’analyse incluent celles créées par les <directives %@ import %>, <%@ reference %>, et <%@ register %> directives. Un contrôle chargé via la méthode LoadControl ne crée pas de dépendance au moment de l’analyse. Notez que global.asax est compilé dans un assembly par lui-même.

    Parfois, une consommation excessive de mémoire est due à un nombre inhabituellement élevé d’assemblys chargés. Par exemple, un site qui affiche des articles d’actualités fonctionne mieux à l’aide d’un petit ensemble de fichiers ASPX qui obtiennent les actualités d’une base de données qu’un seul fichier ASPX utilisé pour chaque article. Les concepteurs de sites doivent essayer de générer du contenu dynamiquement, d’utiliser la mise en cache et de réduire le nombre de pages ASPX et ASCX.

    Les assemblys ne peuvent pas être déchargés à partir d’un AppDomain. Pour éviter une consommation excessive de mémoire, appDomain est déchargé lorsque le nombre de re-compilations (ASPX, ASCX, ASAX) dépasse la limite spécifiée par <la compilation numRecompilesBeforeAppRestart=/>. Notez que si l’attribut <%@ page debug=%> a la valeur true ou si <compilation debug=/> a la valeur true, la compilation par lots est désactivée.

  • Octets dans le tas chargeur. Nombre d’octets validés par le chargeur de classe sur tous les AppDomains. Ce compteur doit atteindre un état stable. Si ce compteur augmente continuellement, surveillez le compteur « Assemblys actuels ». Il peut y avoir trop d’assemblys chargés par AppDomain.

Compteurs de mémoire CLR .NET

Le compteur _Global_ instance ne doit pas être utilisé avec ces compteurs de performances, car il est mis à jour par tous les processus managés. Utilisez plutôt le aspnet_wp instance.

  • Nombre d’octets dans tous les tas. Nombre d’octets validés par des objets managés. Il s’agit de la somme du tas d’objets volumineux et des tas de génération 0, 1 et 2. Ces régions de mémoire sont de type MEM_COMMIT (consultez la documentation du Kit de développement logiciel (SDK) de plateforme pour VirtualAlloc). La valeur de ce compteur est toujours inférieure à la valeur de Process\Private Bytes, qui compte toutes les régions MEM_COMMIT pour le processus. Octets privés moins # Octets dans tous les tas est le nombre d’octets validés par des objets non managés. La première étape de l’examen de l’utilisation excessive de la mémoire consiste à déterminer si elle est utilisée par des objets managés ou non managés.

    Pour examiner l’utilisation excessive de la mémoire managée, je recommande WINDBG.EXE et SOS.DLL, que vous pouvez lire dans Débogage de production pour les applications .NET Framework. SOS.DLL a une commande « !dumpheap –stat » qui répertorie le nombre, la taille et le type d’objets dans le tas managé. Vous pouvez utiliser « !dumpheap –mt » pour obtenir l’adresse d’un objet et « !gcroot » pour voir ses racines. La commande « !eeheap » présente des statistiques d’utilisation de la mémoire pour les tas managés.

    Un autre outil utile pour diagnostiquer l’utilisation de la mémoire est le profileur CLR, décrit plus en détail ci-dessous.

    L'utilisation excessive de la mémoire managée est généralement provoquée par les situations suivantes :

    1. Lecture de groupes de données de grande taille dans la mémoire.
    2. Création d'un nombre excessif d'entrées de cache.
    3. Transfert ou téléchargement de fichiers de grande taille.
    4. Utilisation excessive d'expressions régulières ou de chaînes lors de l'analyse des fichiers.
    5. Affichage excessif.
    6. Trop grand nombre de données dans l'état de session ou trop grand nombre de sessions.

  • # Gen 0 Collections. Nombre de fois où des objets de génération 0 ont été collectés. Les objets qui survivent sont promus à la génération 1. Une collection est effectuée lorsque de l’espace est nécessaire pour allouer un objet, ou quand quelqu’un force une collection en appelant System.GC.Collect. Les collections qui impliquent des générations supérieures prennent plus de temps, car elles sont précédées de collections de générations inférieures. Essayez de réduire le pourcentage de collections de génération 2. En règle générale, le nombre de collections de génération 0 doit être 10 fois supérieur au nombre de collections de génération 1, et de même pour les générations 1 et 2. Les compteurs # Gen N Collections et le compteur % Time in GC sont les meilleurs pour identifier les problèmes de performances causés par des allocations excessives. Consultez la description du pourcentage de temps dans GC pour connaître les étapes à suivre pour améliorer les performances.

  • Collections # Gen 1. Nombre de fois où des objets de génération 1 ont été collectés. Les objets qui survivent sont promus à la génération 2.

    Seuil : un dixième de la valeur des collections #Gen 0. Les applications qui fonctionnent bien suivent la règle générale mentionnée dans la description du compteur collections #Gen 0.

  • Collections # Gen 2. Nombre de fois où des objets de génération 2 ont été collectés. La génération 2 étant la plus élevée, les objets qui survivent à la collection restent dans la génération 2. Les collections Gen 2 peuvent être très coûteuses, surtout si la taille du tas Gen 2 est excessive.

    Seuil : un dixième de la valeur des collections #Gen 1. Les applications qui fonctionnent bien suivent la règle générale mentionnée dans la description du compteur collections #Gen 0.

  • % temps dans le GC. Pourcentage de temps passé à effectuer le dernier garbage collection. Une valeur moyenne de 5 % ou moins serait considérée comme saine, mais les pics plus importants ne sont pas rares. Notez que tous les threads sont suspendus pendant un garbage collection.

    La cause la plus courante d’un pourcentage élevé de temps en GC est d’effectuer trop d’allocations par demande. La deuxième cause la plus courante consiste à insérer une grande quantité de données dans le cache ASP.NET, à les supprimer, à les régénérer et à les réinsérer dans le cache toutes les quelques minutes. Il existe souvent de petites modifications qui peuvent être apportées pour réduire considérablement les allocations. Par exemple, la concaténation de chaînes peut être coûteuse par requête, car les chaînes concaténées doivent être collectées par le garbage collect. StringBuilder, avec une capacité initiale appropriée, fonctionne mieux que la concaténation de chaînes. Toutefois, StringBuilder doit également être récupéré par la mémoire et, s’il est utilisé de manière incorrecte, il peut entraîner plus d’allocations que prévu, car les mémoires tampons internes sont redimensionnées. L’appel de Response.Write plusieurs fois sur chaque chaîne fonctionne encore mieux que de les combiner avec StringBuilder. Si vous pouvez éviter l’altogther StringBuilder, faites-le.

    Les applications stockent souvent des données temporairement dans un StringBuilder ou un MemoryStream lors de la génération d’une réponse. Au lieu de recréer ce stockage temporaire sur chaque requête, envisagez d’implémenter un pool de mémoires tampons réutilisables de tableaux de caractères ou d’octets. Un pool de mémoires tampons est un objet avec une routine GetBuffer et ReturnBuffer . La routine GetBuffer tente de retourner une mémoire tampon à partir d’un magasin interne de mémoires tampons, mais crée une mémoire tampon si le magasin est vide. La routine ReturnBuffer retourne la mémoire tampon dans le magasin si le nombre maximal de mémoires tampons stockées n’a pas encore été atteint, mais le libère sinon. L’inconvénient de cette implémentation de pool de mémoires tampons est qu’elle nécessite un verrouillage pour la sécurité des threads. Vous pouvez également éviter l’impact sur les performances du verrouillage en utilisant HttpContext.ApplicationInstance pour accéder à un champ instance défini dans global.asax. Il existe un instance de global.asax pour chaque instance de pipeline. Par conséquent, le champ n’est accessible qu’à partir d’une seule requête à la fois, ce qui en fait un endroit idéal pour stocker un caractère réutilisable ou une mémoire tampon d’octets.

    Pour réduire le pourcentage de temps dans GC, vous devez connaître votre modèle d’allocation. Utilisez clr Profiler pour profiler une requête unique ou une contrainte légère pendant au maximum quelques minutes. (Ces outils sont invasifs et ne sont pas destinés à être utilisés dans producton.) La vue Graphique d’allocation affiche la mémoire totale allouée pour chaque type d’objet et la pile d’appels qui a effectué l’allocation. Utilisez cette option pour réduire les allocations excessives. L’affichage Histogramme par taille (sélectionnez Histogramme Types alloués dans le menu Affichage) résume la taille des objets alloués. Évitez d’allouer des objets de courte durée de vie supérieure à 85 000 octets. Ces objets sont alloués dans le tas d’objets volumineux et sont plus coûteux à collecter. Dans l’affichage Histogramme par taille, vous pouvez sélectionner des objets avec votre souris et cliquer avec le bouton droit pour voir qui les a alloués. La réduction des allocations est un processus itératif de modifications et de profilage du code.

    Seuil : une moyenne de 5 % ou moins ; les pics à courte durée de vie supérieurs à celui-ci sont fréquents. Les valeurs moyennes supérieures à cette valeur doivent être examinées. Un nouveau seuil doit être défini si nécessaire.

compteurs ASP.NET

Les compteurs de performances de cette catégorie ne sont réinitialisés à 0 que lorsque le service w3svc est démarré.

  • L’application redémarre. Nombre de redémarrages d’application. La recréation du domaine d’application et la recompilation des pages prennent du temps. Par conséquent, les redémarrages d’application imprévus doivent être examinés. Le domaine d’application est déchargé lorsque l’un des événements suivants se produit :

    • Modification de machine.config, web.configou global.asax.
    • Modification du répertoire bin de l’application ou de son contenu.
    • Lorsque le nombre de compilations (ASPX, ASCX ou ASAX) dépasse la limite spécifiée par <la compilation numRecompilesBeforeAppRestart=/>.
    • Modification du chemin physique d’un répertoire virtuel.
    • Modification de la stratégie de sécurité d’accès au code.
    • Le service web est redémarré.

    Pour les batteries de serveurs Web en production, il est recommandé de supprimer un serveur de la rotation avant de mettre à jour le contenu pour optimiser les performances et la fiabilité. Pour un serveur web unique en production, le contenu peut être mis à jour pendant que le serveur est sous charge. Le correctif logiciel décrit dans l’article de la Base de connaissances 810281 est intéressant pour toute personne rencontrant des erreurs après le redémarrage d’une application, comme le partage de violations avec une erreur similaire à « Impossible d’accéder au fichier <FileName> car il est utilisé par un autre processus ».

    Un problème impliquant le redémarrage des logiciels antivirus et des applications est résolu dans l’article 820746 de la Base de connaissances : CORRECTIF : Certains programmes antivirus peuvent provoquer un redémarrage inattendu des applications web pour la version 1.0, et dans l’article de la Base de connaissances 821438 pour la version 1.1.

    Seuil : 0. Dans un monde parfait, le domaine d’application survivra pendant toute la durée du processus. Les valeurs excessives doivent être examinées et un nouveau seuil doit être défini si nécessaire.

  • Applications en cours d’exécution. Nombre d’applications en cours d’exécution.

  • Demandes actuelles. Nombre de demandes actuellement gérées par le ASP.NET ISAPI. Cela inclut ceux qui sont mis en file d’attente, en cours d’exécution ou en attente d’écriture dans le client. Ce compteur de performances a été ajouté à la version 1.0 de ASP.NET dans le correctif logiciel pré-SP3 décrit dans l’article 329959 de la Base de connaissances.

    ASP.NET commencez à rejeter les demandes lorsque ce compteur dépasse la valeur requestQueueLimit définie dans la section de configuration processModel . Notez que requestQueueLimit s’applique à ASP.NET sur IIS 5.0 lors de l’exécution dans aspnet_wp, mais peut-être surprenant, il s’applique également à IIS 6.0 lors de l’exécution dans w3wp. Il n’est pas bien connu que plusieurs paramètres de configuration processModel s’appliquent toujours lors de l’exécution dans IIS 6.0. Il s’agit notamment de requestQueueLimit, responseDeadlockInterval, maxWorkerThreads, maxIoThreads, minWorkerThreads et minIoThreads. Un bogue dans la version 1.1 du Framework, résolu dans ASP.NET 1.1 juin 2003 Correctif cumulatif, a permis à ASP.NET de gérer un nombre infini de demandes lors de l’exécution d’IIS 6.0. Le correctif entraîne ASP.NET à rejeter les demandes lorsque les demandes en cours dépassent la limite requestQueueLimit.

    Pour les applications ASP classiques, demandes mises en file d’attente fournit un avertissement indiquant quand les demandes seront rejetées. Pour ASP.NET, les requêtes actuelles, ainsi que les demandes dans la file d’attente d’applications, fournissent cette fonctionnalité. Ce compteur est également utilisé par le mécanisme de détection d’interblocage ASP.NET. Si requêtes en cours est supérieure à 0 et qu’aucune réponse n’a été reçue du processus de travail pendant une durée supérieure à la limite spécifiée par <processModel responseDeadlockInterval=/>, le processus est terminé et un nouveau processus est démarré. Dans le correctif logiciel pré-SP3 décrit dans l’article 328267 de la Base de connaissances, l’algorithme a été modifié de sorte que les demandes actuelles doivent être supérieures à la somme de maxWorkerThreads plus maxIoThreads, spécifiée dans la < section processModel/>configuration. Notez que par défaut, le délai d’exécution de la requête est de 90 secondes et est intentionnellement inférieur à responseDeadlockInterval. Le délai d’exécution de la demande peut être modifié via le < paramètre de configuration httpRuntime executionTimeout=/> ou la propriété Server.ScriptTimeout, mais il doit toujours être inférieur à responseDeadlockInterval.

  • Heure d’exécution de la demande. Nombre de millisecondes nécessaires pour exécuter la dernière requête. Dans la version 1.0 de l’infrastructure, le temps d’exécution commence lorsque le processus de travail reçoit la demande et s’arrête lorsque le ASP.NET ISAPI envoie HSE_REQ_DONE_WITH_SESSION à IIS. Pour IIS version 5, cela inclut le temps nécessaire à l’écriture de la réponse sur le client, mais pour IIS version 6, les mémoires tampons de réponse sont envoyées de manière asynchrone, de sorte que le temps nécessaire à l’écriture de la réponse au client n’est pas inclus. Ainsi, sur IIS version 5, un client avec une connexion réseau lente augmente considérablement la valeur de ce compteur.

    Dans la version 1.1 de l’infrastructure, le temps d’exécution commence lorsque le HttpContext de la demande est créé et s’arrête avant que la réponse soit envoyée à IIS. En supposant que le code utilisateur n’appelle pas HttpResponse.Flush, cela implique que le temps d’exécution s’arrête avant d’envoyer des octets à IIS, ou au client d’ailleurs.

    ASP.NET\Request Execution Time est un compteur instance et très volatile. D’autre part, le temps de dernière octet (TTLB) peut être facilement moyenné et utilisé pour calculer une meilleure estimation des performances sur une période de temps. TTLB peut être calculé via un client HTTP simple écrit en code managé, ou vous pouvez utiliser l’un des nombreux clients HTTP disponibles qui calculent TTLB, comme Application Center Test (ACT).

    Notez que si <la compilation debug=/> est définie sur TRUE, la compilation par lots sera désactivée et le < paramètre de configuration httpRuntime executionTimeout=/> ainsi que les appels à Server.ScriptTimeout seront ignorés. Cela peut entraîner des problèmes si le < paramètre processModel responseDeadlockInterval=/> n’est pas défini sur Infinite, car les demandes de pages de débogage peuvent théoriquement s’exécuter indéfiniment.

    Seuil : N.A. La valeur de ce compteur doit être stable. L’expérience vous aidera à définir un seuil pour un site particulier. Lorsque le modèle de processus est activé, le temps d’exécution de la demande inclut le temps nécessaire pour écrire la réponse au client et dépend donc de la bande passante de la connexion du client.

  • Demandes en file d’attente. Nombre de demandes actuellement en file d’attente. Lors de l’exécution sur IIS 5.0, il existe une file d’attente entre inetinfo et aspnet_wp, et il existe une file d’attente pour chaque répertoire virtuel. Lors de l’exécution sur IIS 6.0, il existe une file d’attente où les demandes sont publiées dans le ThreadPool managé à partir du code natif, ainsi qu’une file d’attente pour chaque répertoire virtuel. Ce compteur inclut les requêtes dans toutes les files d’attente. La file d’attente entre inetinfo et aspnet_wp est un canal nommé par lequel la demande est envoyée d’un processus à l’autre. Le nombre de demandes dans cette file d’attente augmente en cas de pénurie de threads d’E/S disponibles dans le processus aspnet_wp. Sur IIS 6.0, il augmente en cas de demandes entrantes et de pénurie de threads de travail.

    Notez que les demandes sont rejetées lorsque le compteur Demandes actuelles dépasse la <requête processModel RequestQueueLimit=/>. De nombreuses personnes pensent que cela se produit lorsque le compteur Demandes mises en file d’attente dépasse requestQueueLimit, mais ce n’est pas le cas. Lorsque cette limite est dépassée, les demandes sont rejetées avec un code 503 status et le message « Le serveur est trop occupé ». Si une demande est rejetée pour cette raison, elle n’atteint jamais le code managé et les gestionnaires d’erreurs ne sont pas avertis. Normalement, il ne s’agit d’un problème que lorsque le serveur est soumis à une charge très lourde, même si une charge « rafale » toutes les heures peut également en être l’origine. Pour le scénario de chargement en rafale inhabituel, vous pouvez être intéressé par le correctif logiciel décrit dans l’article 810259 de la Base de connaissances, qui vous permettra d’augmenter le nombre minimal de threads d’E/S à partir de la valeur par défaut de 1 par processeur.

    Chaque répertoire virtuel a une file d’attente qu’il utilise pour maintenir la disponibilité des threads worker et E/S. Le nombre de demandes dans cette file d’attente augmente si le nombre de threads de travail disponibles ou de threads d’E/S disponibles est inférieur à la limite spécifiée par <httpRuntime minFreeThreads=/>. Lorsque la limite spécifiée par <httpRuntime appRequestQueueLimit=/> est dépassée, la demande est rejetée avec un code 503 status et le client reçoit une httpException avec le message « Serveur trop occupé ».

    En soi, ce compteur n’est pas un indicateur clair des problèmes de performances et ne peut pas être utilisé pour déterminer quand les demandes seront rejetées. Dans l’article 329959 de la Base de connaissances, deux nouveaux compteurs de performances ont été introduits pour résoudre ce problème : requêtes actuelles et demandes dans la file d’attente d’applications. Consultez les descriptions de ces deux compteurs, ainsi que pour les demandes rejetées.

  • Demandes rejetées. Nombre de demandes rejetées. Les demandes sont rejetées lorsque l’une des limites de file d’attente est dépassée (voir description des demandes mises en file d’attente). Les demandes peuvent être rejetées pour plusieurs raisons. La latence du back-end, telle que celle provoquée par un serveur SQL lent, est souvent précédée d’une augmentation soudaine du nombre d’instances de pipeline et d’une diminution de l’utilisation du processeur et des requêtes/s. Un serveur peut être débordé pendant les périodes de charge importante en raison de contraintes de processeur ou de mémoire qui finissent par entraîner le rejet des demandes.

    La conception d’une application peut entraîner un temps d’exécution de requête excessif. Par exemple, la compilation par lots est une fonctionnalité dans laquelle toutes les pages d’un répertoire sont compilées dans un assembly unique lorsque la première demande d’une page est reçue. S’il existe plusieurs centaines de pages dans un répertoire, l’exécution de la première requête dans ce répertoire peut prendre beaucoup de temps. Si <la compilation batchTimeout=/> est dépassée, la compilation par lots se poursuit sur un thread d’arrière-plan et la page demandée est compilée individuellement. Si la compilation par lots réussit, l’assembly est conservé sur disque et peut être réutilisé après le redémarrage d’une application. Toutefois, si l’assembly global.asax, web.config, machine.config ou un assembly dans le dossier bin de l’application est modifié, le processus de compilation par lots s’exécute à nouveau en raison de la modification de la dépendance.

    Une conception soignée d’un grand site peut avoir un impact significatif sur les performances. Dans ce cas, il est préférable de n’avoir que quelques pages qui varient le comportement en fonction des données de chaîne de requête. En règle générale, vous devez réduire le temps d’exécution des requêtes, qui est mieux surveillé en moyenne du temps de dernière octet (TTLB) à l’aide d’un client HTTP qui demande une ou plusieurs pages à partir du site web.

    Les compteurs de performances suivants sont les mieux adaptés à la découverte de la cause des demandes rejetées :

    • Processus\% temps processeur
    • Processus\Octets privés
    • Processus\Nombre de threads
    • Service web\Demandes d’extension ISAPI/s
    • ASP.NET\Requêtes actuelles
    • ASP.NET\Requêtes en file d’attente
    • ASP.NET\Délai d’attente de la demande
    • ASP.NET Applications\Nombre d’instances de pipeline
    • ASP.NET Applications\Requêtes dans la file d’attente d’applications

    Seuil : 0. La valeur de ce compteur doit être 0. Les valeurs supérieures doivent être examinées.

  • Demander un délai d’attente. Nombre de millisecondes que la demande la plus récente a passées à attendre dans la file d’attente, ou le canal nommé, qui existe entre inetinfo et aspnet_wp (voir la description des demandes mises en file d’attente). Cela n’inclut pas le temps passé à attendre dans les files d’attente des applications.

    Seuil : 1000. La requête moyenne doit passer 0 milliseconde à attendre dans la file d’attente.

  • Processus de travail en cours d’exécution. Nombre actuel de processus de travail aspnet_wp. Pendant une courte période, un nouveau processus de travail et le processus de travail en cours de remplacement peuvent coexister. Bien que rare, les processus parfois d’interblocage pendant leur sortie. Si vous soupçonnez cela, envisagez d’utiliser un outil pour surveiller le nombre d’instances du processus de travail. Vous pouvez également utiliser le compteur de performances Mémoire\Mbytes disponibles, car ces processus suspendus consomment de la mémoire.

    Seuil : 2. Lors de l’arrêt du processus de travail précédent, il peut y avoir deux instances. Si webGarden est activé, le seuil doit être #CPUs plus 1. Des valeurs supérieures à cette valeur peuvent indiquer des redémarrages excessifs du processus dans un laps de temps très court.

  • Redémarrages du processus de travail. Nombre de aspnet_wp processus redémarre.

    Seuil : 1. Les redémarrages de processus sont coûteux et indésirables. Les valeurs dépendent des paramètres de configuration du modèle de processus, ainsi que des violations d’accès imprévues, des fuites de mémoire et des interblocages. Si aspnet_wp redémarre, une entrée du journal des événements d’application indique pourquoi. Les demandes seront perdues en cas de violation d’accès ou d’interblocage. Si les paramètres du modèle de processus sont utilisés pour recycler le processus de manière préventive, il est nécessaire de définir un seuil approprié.

compteurs d’applications ASP.NET

Les compteurs de performances de cette catégorie sont réinitialisés à 0 lorsque le domaine d’application ou le service Web est redémarré.

  • Entrées totales de cache. Nombre actuel d’entrées dans le cache (utilisateur et interne). En interne, ASP.NET utilise le cache pour stocker des objets coûteux à créer, notamment des objets de configuration, des entrées d’assembly conservées, des chemins d’accès mappés par la méthode MapPath et des objets d’état de session en cours de traitement.

    Note La famille de compteurs de performances « Cache Total » est utile pour diagnostiquer les problèmes liés à l’état de session in-process. Le stockage d’un trop grand nombre d’objets dans le cache est souvent à l’origine de fuites de mémoire.

  • Taux d’accès total du cache. Ratio total accès/absence de toutes les demandes de cache (utilisateur et interne).

  • Taux de rotation total du cache. Nombre d’ajouts et de suppressions dans le cache par seconde (utilisateur et interne). Un taux de rotation élevé indique que les éléments sont rapidement ajoutés et supprimés, ce qui peut s’avérer coûteux.

  • Entrées d’API de cache. Nombre d’entrées actuellement dans le cache utilisateur.

  • Taux d’accès de l’API cache. Ratio accès/absence total des demandes de cache utilisateur.

  • Taux de renouvellement de l’API de cache. Nombre d’ajouts et de suppressions dans le cache utilisateur par seconde. Un taux de rotation élevé indique que les éléments sont rapidement ajoutés et supprimés, ce qui peut s’avérer coûteux.

  • Entrées de cache de sortie. Nombre d’entrées actuellement dans le cache de sortie.

  • Taux d’accès au cache de sortie. Ratio total accès/absence des demandes de cache de sortie.

  • Taux de rotation du cache de sortie. Nombre d’ajouts et de suppressions dans le cache de sortie par seconde. Un taux de rotation élevé indique que les éléments sont rapidement ajoutés et supprimés, ce qui peut s’avérer coûteux.

  • Nombre d’instances de pipeline. Nombre d’instances de pipeline actives. Un seul thread d’exécution peut s’exécuter dans un pipeline instance. Ce nombre indique donc le nombre maximal de demandes simultanées qui sont traitées pour une application donnée. Le nombre d’instances de pipeline doit être stable. Les augmentations soudaines indiquent la latence du back-end (voir la description des demandes rejetées ci-dessus).

  • Total des compilations. Nombre de fichiers ASAX, ASCX, ASHX, ASPX ou ASMX compilés. Il s’agit du nombre de fichiers compilés, et non du nombre d’assemblys générés. Les assemblys sont conservés sur disque et réutilisés jusqu’à ce que l’heure de création, l’heure de la dernière écriture ou la longueur d’une dépendance de fichier change. Les dépendances d’une page ASPX incluent global.asax, web.config, machine.config, assemblys dépendants dans le dossier bin et fichiers ASCX référencés par la page. Si vous redémarrez l’application sans modifier les dépendances de fichier, l’assembly conservé est rechargé sans nécessiter de compilation. Ce compteur de performances s’incrémente uniquement lorsqu’un fichier est initialement analysé et compilé dans un assembly.

    Par défaut, la compilation par lots est activée. Toutefois, ce compteur est incrémenté une fois pour chaque fichier analysé et compilé dans un assembly, quel que soit le nombre d’assemblys créés.

    Si la compilation échoue, le compteur n’est pas incrémenté.

  • Erreurs pendant le prétraitement. Nombre total d’erreurs de configuration et d’analyse. Ce compteur est incrémenté chaque fois qu’une erreur de configuration ou d’analyse se produit. Même si les erreurs de configuration sont mises en cache, le compteur s’incrémente chaque fois que l’erreur se produit.

    Note Ne vous fiez pas uniquement aux compteurs de performances « Erreurs » pour déterminer si le serveur est sain. Ils sont réinitialisés à zéro lorsque l’AppDomain est déchargé. Toutefois, ils peuvent être utilisés pour approfondir un problème spécifique. En général, utilisez l’événement Application_Error pour alerter les administrateurs en cas de problèmes.

  • Erreurs pendant la compilation. Nombre total d’erreurs de compilation. La réponse est mise en cache, et ce compteur ne s’incrémente qu’une seule fois jusqu’à ce que la recompilation soit forcée par une modification de fichier. Implémentez une gestion des erreurs personnalisée pour déclencher un événement.

  • Erreurs lors de l’exécution. Nombre total d’erreurs d’exécution.

  • Erreurs non gérées pendant l’exécution. Nombre total d’exceptions non gérées au moment de l’exécution. Cela n’inclut pas les éléments suivants :

    1. Erreurs effacées par un gestionnaire d’événements (par exemple, par Page_Error ou Application_Error).
    2. Erreurs gérées par une page de redirection.
    3. Erreurs qui se produisent dans un bloc try/catch.

  • Erreurs non gérées pendant l’exécution/s. Nombre total d’exceptions non gérées par seconde au moment de l’exécution.

  • Nombre total d’erreurs. Somme des erreurs pendant le prétraitement, des erreurs pendant la compilation et des erreurs pendant l’exécution.

  • Erreurs Total/s. Total des erreurs pendant le prétraitement, des erreurs pendant la compilation et des erreurs pendant l’exécution par seconde.

  • Requêtes en cours d’exécution. Nombre de requêtes en cours d’exécution. Ce compteur est incrémenté lorsque HttpRuntime commence à traiter la requête et est décrémenté une fois que HttpRuntime a terminé la requête. Dans la version 1.1 de l’infrastructure, il existe un bogue dans ce compteur de performances qui est résolu dans le package correctif cumulatif ASP.NET 1.1 juin 2003. Malheureusement, le bogue n’est pas décrit dans l’article de la Base de connaissances. Avant le correctif, le compteur incluait le temps nécessaire pour écrire la réponse au client.

  • Demandes dans la file d’attente des applications. Nombre de demandes dans la file d’attente des demandes d’application (voir la description des demandes mises en file d’attente ci-dessus). En plus des demandes actuelles, demandes dans la file d’attente d’applications fournit un avertissement indiquant quand les demandes seront rejetées. S’il n’existe que quelques répertoires virtuels, l’augmentation de la valeur appRequestQueueLimit par défaut à 200 ou 300 peut convenir, en particulier pour les applications lentes sous une charge lourde.

  • Requêtes introuvables. Nombre de demandes de ressources introuvables.

  • Demandes non autorisées. Le nombre de demandes a échoué en raison d’un accès non autorisé.

  • Demandes expirées. Nombre de demandes qui ont expiré.

  • Demandes réussies. Nombre de demandes qui ont été exécutées avec succès.

  • Nombre total de demandes. Nombre de demandes depuis le démarrage de l’application.

  • Demandes/s. Nombre de requêtes exécutées par seconde. Je préfère « Web Service\ISAPI Extension Requests/s », car il n’est pas affecté par les redémarrages de l’application.

Compteurs de processus

Avec ces compteurs, les processus intéressants sont aspnet_wp et inetinfo.

  • % de temps processeur. Pourcentage de temps que les threads de ce processus passent à utiliser les processeurs.

    Seuil : 70 %. Les valeurs supérieures à ce pendant de longues périodes indiquent la nécessité d’acheter du matériel ou d’optimiser votre application.

  • Nombre de handles.

    Seuil : 10000. Un nombre de handles de 2000 dans aspnet_wp est suspect, et 10 000 est bien au-delà des limites acceptables. Une dégradation notable des performances se produit si le nombre total de handles pour tous les processus dépasse environ 40 000, ce qui est entièrement réalisable lors d’une attaque par déni de service contre IIS.

  • Octets privés. Taille actuelle, en octets, de la mémoire validée appartenant à ce processus. Les fuites de mémoire sont identifiées par une augmentation cohérente et prolongée des octets privés. Il s’agit du meilleur compteur de performances pour détecter les fuites de mémoire.

    Lors de l’exécution sur IIS 5.0, une limite de mémoire pour les octets privés doit être définie dans la <section de configuration processModel memoryLimit=/> . Lors de l’exécution sur IIS 6.0, la limite de mémoire doit être définie dans le Gestionnaire des services Internet. Ouvrez Propriétés pour le pool d’applications et, sous l’onglet Recyclage, spécifiez une limite de mémoire maximale utilisée (en mégaoctets). Cette limite correspond aux octets privés. Les octets privés pour le processus worker sont comparés à la limite de mémoire pour déterminer quand recycler le processus. System.Web.Caching.Cache utilise également des octets privés et la limite de mémoire pour déterminer quand supprimer des éléments du cache et éviter ainsi de recycler le processus. Une limite de mémoire de 60 % de la RAM physique est recommandée pour éviter la pagination, en particulier lorsqu’un nouveau processus remplace l’ancien en raison d’une consommation excessive de mémoire. Notez que l’article 330469 de la Base de connaissances résout un problème de ASP.NET dans lequel il ne parvient pas à surveiller les octets privés sur les serveurs avec un grand nombre de processus en cours d’exécution. Ce correctif logiciel permet également au gestionnaire de mémoire du cache de fonctionner correctement lorsqu’il existe un grand nombre de processus en cours d’exécution.

    Il est important d’ajuster la limite de mémoire sur les ordinateurs avec de grandes quantités de RAM physique, afin que le gestionnaire de mémoire du cache et le processus de recyclage fonctionnent correctement. Par exemple, supposons que vous ayez un serveur avec 4 gigaoctets (Go) de RAM physique qui utilise la limite de mémoire par défaut. Cela pose un problème. Soixante pour cent de la RAM physique est de 2,4 Go, ce qui est supérieur à l’espace d’adressage virtuel par défaut de 2 Go. À quoi la limite de mémoire doit-elle être définie ?

    Il y a deux points à prendre en compte : Tout d’abord, la probabilité de rencontrer une exception OutOfMemoryException commence à augmenter considérablement lorsque « Process\Virtual Bytes » se trouve dans les 600 Mo de la limite d’espace d’adressage virtuel (généralement 2 Go), et d’autre part, les tests ont montré que « Process\Virtual Bytes » est souvent supérieur à « Process\Private Bytes » d’au plus 600 Mo. Cette différence est due en partie à la MEM_RESERVE régions gérées par le gc, ce qui lui permet de valider rapidement plus de mémoire en cas de besoin. Dans l’ensemble, cela implique que lorsque « Process\Private Bytes » dépasse 800 Mo, la probabilité de rencontrer une exception OutOfMemoryException augmente. Dans cet exemple, l’ordinateur dispose de 4 Go de RAM physique. Vous devez donc définir la limite de mémoire sur 20 % pour éviter les conditions de mémoire insuffisante. Vous pouvez expérimenter ces nombres pour optimiser l’utilisation de la mémoire sur un ordinateur, mais si vous souhaitez l’utiliser en toute sécurité, les nombres de l’exemple fonctionneront.

    Pour résumer, définissez la limite de mémoire sur la plus petite de 60 % de LA RAM physique ou de 800 Mo. Étant donné que la version 1.1 prend en charge 3 Go d’espace d’adressage virtuel, si vous ajoutez /3 Go à boot.ini, vous pouvez utiliser en toute sécurité 1 800 Mo au lieu de 800 Mo comme limite supérieure.

    Notez que lorsque vous exécutez des tests, si vous souhaitez forcer un GC et stabiliser la mémoire managée, vous pouvez appeler System.GC.GetTotalMemory(true) une seule fois. Cette méthode appelle GC. Collect et WaitForPendingFinalizers() à plusieurs reprises jusqu’à ce que la mémoire se stabilise dans les 5 %.

    Seuil : minimum de 60 % de ram physique et 800 Mo. Les valeurs supérieures à 60 % de la ram physique totale commencent à avoir un impact sur les performances, en particulier pendant les redémarrages d’application et de processus. La liklihood d’une exception OutOfMemoryException augmente considérablement lorsque les octets privés dépassent 800 Mo dans un processus avec une limite d’espace d’adressage virtuel de 2 Go.

  • Nombre de threads. Nombre de threads actifs dans ce processus. Le nombre de threads augmente souvent lorsque la charge est trop élevée.

    Seuil : 75 + ((maxWorkerThread + maxIoThreads) * #CPUs). Le seuil doit être augmenté si le mode aspcompat est utilisé : Seuil : 75 + ((maxWorkerThread + maxIoThreads) * #CPUs * 2).

  • Octets virtuels. Taille actuelle, en octets, de l’espace d’adressage virtuel pour ce processus.

    La limite d’espace d’adressage virtuel d’un processus en mode utilisateur est de 2 Go, sauf si l’espace d’adressage de 3 Go est activé à l’aide du commutateur /3 Go dans boot.ini. Les performances se dégradent à l’approche de cette limite et entraînent généralement un blocage du processus ou du système. L’espace d’adressage devient fragmenté à mesure que la limite de 2 Go ou 3 Go est proche, et je recommande donc un seuil conservateur de 1,4 ou 2,4 Go, respectivement. Si vous rencontrez des problèmes ici, system.OutOfMemoryException est levée, ce qui peut ou non bloquer le processus.

    Lors de l’exécution sur IIS 6.0, une limite de mémoire virtuelle peut être définie dans le Gestionnaire des services Internet. Toutefois, une définition incorrecte de ce paramètre peut entraîner des problèmes de ASP.NET. ASP.NET expurge les éléments du cache pour éviter de dépasser la limite d’octets privés, mais l’algorithme utilise des octets privés et la limite d’octets privés dans cette détermination. Il ne surveille pas les octets virtuels ou la limite d’octets virtuels. Étant donné que la différence entre les octets virtuels et les octets privés n’est généralement pas supérieure à 600 Mo, vous pouvez définir la limite d’octets virtuels sur une valeur supérieure de 600 Mo à la limite d’octets privés si vous êtes préoccupé par la possibilité de fuites de mémoire virtuelle ou de fragmentation. Si cela est souhaitable, définissez une limite de mémoire virtuelle maximale (en mégaoctets) sous l’onglet Recyclage pour les propriétés du pool d’applications.

    La version 1.0 de l’infrastructure ne prend pas en charge 3 Go d’espace d’adressage dans le processus de travail ou le service d’état. Toutefois, consultez l’article 320353 de la Base de connaissances pour obtenir des instructions sur l’activation de 3 Go d’espace d’adressage dans inetinfo.exe. La version 1.1 prend entièrement en charge 3 Go d’espace d’adressage pour le processus de travail et le service d’état.

    Seuil : 600 Mo de moins que la taille de l’espace d’adressage virtuel ; 1,4 ou 2,4 Go.

Compteur de processeur

  • % de temps processeur. Pourcentage de temps que tous les threads passent à utiliser les processeurs.

    Seuil : 70 %. Les valeurs supérieures à ce pendant de longues périodes indiquent la nécessité d’acheter du matériel ou d’optimiser votre application.

Compteur de mémoire

  • Octets disponibles. Quantité de RAM physique disponible.

    Seuil : 20 % de la RAM physique. Les valeurs inférieures à doivent être examinées et peuvent indiquer la nécessité d’acheter du matériel.

Compteur système

  • Commutateurs de contexte/s. Vitesse à laquelle les processeurs changent de contexte de thread. Un nombre élevé peut indiquer une contention de verrouillage élevée ou des transitions entre le mode utilisateur et le mode noyau. Les commutateurs de contexte/s doivent augmenter linéairement avec le débit, la charge et le nombre de processeurs. S’il augmente de façon exponentielle, il y a un problème. Un profileur doit être utilisé pour une investigation plus approfondie.

Compteurs de service web

  • Connexions actuelles. Un seuil pour ce compteur dépend de nombreuses variables, telles que le type de requêtes (ISAPI, CGI, HTML statique, etc.), l’utilisation du processeur, etc. Un seuil doit être développé par l’expérience.
  • Total des demandes de méthode/s. Utilisé principalement comme métrique pour diagnostiquer les problèmes de performances. Il peut être intéressant de comparer cela avec « ASP.NET Applications\Requests/s » et « Web Service\ISAPI Extension Requests/s » afin de voir le pourcentage de pages statiques servies par rapport aux pages rendues par aspnet_isapi.dll.
  • Demandes d’extension ISAPI/s. Utilisé principalement comme métrique pour diagnostiquer les problèmes de performances. Il peut être intéressant de comparer cela avec « ASP.NET Applications\Requests/s » et « Web Service\Total Method Requests/sec ». Notez que cela inclut les requêtes adressées à toutes les extensions ISAPI, pas seulement aspnet_isapi.dll.

Conclusion

Le stress et les tests de performances minutieux d’une application avant la mise en ligne peuvent éviter un mal de tête majeur. Il semble y avoir deux points d’achoppement majeurs que beaucoup de gens rencontrent :

  1. Vous devez utiliser un client HTTP capable de simuler le trafic et la charge que vous attendez du site Web.
  2. Vous devez tester l’ensemble de l’application dans un environnement presque identique à l’environnement de production.

Il n’est pas facile de simuler le trafic réel du site Web, mais je peux dire honnêtement que la plupart des applications qui rencontrent des problèmes n’ont jamais été suffisamment testées. Cet article doit vous aider à comprendre les compteurs de performances et à créer des outils utiles pour surveiller les performances. Pour appliquer la charge, je recommande Microsoft Application Center Test (ACT), qui est inclus avec Microsoft® Visual Studio® .NET. Pour en savoir plus sur cet outil de stress , consultez Microsoft Application Center Test 1.0, Visual Studio .NET Edition. Je recommande également Microsoft® Web Application Stress Tool (WAST). Vous pouvez le télécharger gratuitement à partir de TechNet. Si votre application utilise ViewState, vous devez utiliser ACT, car WAST ne peut pas analyser dynamiquement la réponse.

Je ne sais pas ce qu’il s’agit des environnements de production, mais il y a certainement quelque chose de spécial à leur sujet. Je ne peux pas compter les fois où j’ai entendu la déclaration : « Le problème ne se produit que sur notre site de production ». En règle générale, la différence est l’application elle-même. Il existe souvent une partie de l’application qui ne peut pas être simulée dans le laboratoire. Par exemple, le serveur publicitaire a été omis du test, ou la base de données utilisée pour simuler la base de données réelle est sensiblement différente. Parfois, les différences réseau ou DNS en sont la cause, et parfois il s’agit d’une différence dans le matériel sur lequel les serveurs s’exécutent.

Je débogue et surveille les performances des applications ASP.NET depuis plusieurs années, mais j’ai encore besoin d’aide à certains moments. Si vous vous trouvez dans cette position, les forums sur le site web ASP.NET sont un bon endroit pour obtenir des réponses. Mais si vous êtes vraiment lié, n’hésitez pas à contacter le support technique Microsoft en utilisant les informations de contact fournies sur ce site. Notez que si microsoft détermine qu’un problème est le résultat d’un défaut dans un produit Microsoft, vous ne serez pas facturé pour cet incident.

Espérons que ce document vous a équipé des outils et des informations dont vous avez besoin pour garantir la fiabilité et les performances de votre application. Si vous avez des questions, publiez-les sur ASP.NET Web et je ferai de mon mieux pour y répondre. Bonne chance !

À propos de l’auteur

Thomas Marquardt est développeur au sein de l’équipe ASP.NET chez Microsoft. Depuis l’hiver 2000, il débogue et étudie les problèmes de performances liés aux applications ASP.NET. Thomas tient à remercier Dmitry Robsman, responsable du développement pour ASP.NET chez Microsoft, pour les heures et les heures d’aide et d’aide au fil des ans.

© Microsoft Corporation. Tous droits réservés.