ASP.NET MVC - Tutoriel sur Glimpse

Repérer la source d'un problème de performances dans une application est parfois un vrai casse-tête. C'est encore plus dur dans le cas d'une application Web ASP.NET MVC ; les points d'extensibilités où le développeur peut accrocher du code sont nombreux et il devient parfois complexe de connaître exactement le chemin de code emprunté à l'exécution d'une requête. De la même manière, il est parfois intéressant de pouvoir explorer d'un coup d'œil les variables de session définies sur un serveur, le contenu du cache, les variables d'environnement. Enfin, pouvoir d'un coup d'œil descendre encore plus bas dans le traitement de sa requête et analyser les performances SQL nécessite généralement d'ajouter une couche d'instrumentation différente de celle utilisée pour le reste de l'application Web…

Sauf que les développeurs .NET ont à leur disposition depuis maintenant quelques années un outil encore trop méconnu : Glimpse.

Dans sa version standard, l'outil est capable de répondre à tous les besoins évoqués ci-dessus, et même plus. Cerise sur le gâteau, ses développeurs l'ont rendu modulaire et extensible à souhait, ce qui fait qu'il est doté d'une galerie d'extensions très fournie et animée par la communauté des développeurs pour répondre à une quantité de besoins encore plus large :

• consulter l'état des types et instances enregistrés dans un conteneur IoC (pour tous les plus gros conteneurs utilisés en .NET) ;
• profiler la connexion avec une base NoSQL telle que RavenDb ;
• afficher la liste des Claims ADFS de l'utilisateur courant ;
• diagnostiquer l'utilisation de SignalR dans votre application.

Visuellement, Glimpse ressemble à une barre d'outils développeur d'un navigateur Internet. Ainsi, après avoir activé Glimpse, on se retrouve avec une fenêtre injectée directement en HTML dans les pages de l'application. Cette fenêtre se compose de plusieurs onglets (tabs), chacun correspondant à une fonctionnalité d'analyse ou de monitoring.

La page du projet est disponible sur http://getglimpse.com/.

Glimpse est disponible sous la forme d'un ensemble de paquets Nuget. Le seul prérequis est une application ASP.NET utilisant le Framework .NET 3.5 ou une version supérieure, WebForms ou ASP.NET MVC, c'est au choix. Il vous faut également bien évidemment un serveur Web ; IIS, IIS Express ou Cassini, n'importe lequel des trois fera très bien l'affaire.

Une fois Visual Studio lancé, ouvrez la console Nuget et recherchez l'un des paquets suivants selon vos besoins :

• Glimpse.Core, c'est le noyau de Glimpse qui contient le Framework de l'outil et tout ce qui est nécessaire à son extensibilité. C'est le prérequis obligatoire de tous les autres paquets ;
• Glimpse.AspNet, c'est la bibliothèque nécessaire pour utiliser Glimpse dans une application WebForms. Il s'agit également d'un prérequis pour pouvoir utiliser Glimpse pour ASP.NET MVC. Elle contient notamment le code nécessaire à l'instrumentation des routes ;
• Glimpse.MvcX, où X est la version du Framework ASP.NET MVC que vous utilisez dans votre projet. Installer directement ce paquet tire automatiquement les deux paquets précédents.

Et si vous voulez en plus monitorer votre accès aux données, vous pouvez également ajouter les paquets suivants :

• Glimpse.ADO, pour ceux qui se passent d'un ORM;
• Glimpse.EFX, où le X correspond à la version d'Entity Framework utilisée.

Pour tous les autres besoins, ou par pure curiosité, la liste complète des extensions pour Glimpse est disponible ici.

L'installation via Nuget va automatiquement faire des modifications dans le fichier web.config de l'application, nous verrons lesquelles dans la suite de ce billet.

Glimpse se présente sous la forme d'un gestionnaire HTTP. Il est accessible à partir d'une URL de type http://localhost/application/glimpse.axd. En naviguant vers cette URL, le gestionnaire vous retournera une page d'où vous pouvez activer (ou désactiver Glimpse). Vous y trouverez également des informations sur la configuration de l'outil, et notamment les différentes extensions activées, et des pointeurs vers la documentation officielle.

Sur cette page donc, les boutons Turn Glimpse On et Turn Glimpse Off vont permettre respectivement d'activer et de désactiver l'outil. En cliquant sur Turn Glimpse On, le gestionnaire HTTP va déposer un cookie (nommé glimpsePolicyavec une valeur à On) dans le navigateur du client. Ce cookie sera ensuite utilisé par le module HTTP de Glimpse, nous y reviendrons dans la prochaine partie de ce billet. En cliquant sur l'autre bouton, Turn Glimpse Off, la valeur du cookie glimpsePolicydevient maintenant une chaîne de caractères vide.

En retournant sur mon application Web (et donc, en quittant la page ~/glimpse.axd du gestionnaire de Glimpse), je peux maintenant voir qu'une barre est apparue et reste fixée dans le bas de ma page. Cette barre présente en un coup d'œil trois types d'informations :

• le temps de traitement de la requête du client par segment : le temps passé en échange réseau, le temps passé côté serveur et enfin le temps utilisé par le navigateur pour charger et afficher le DOM ;
• le couple controller/action sélectionné et le temps de traitement de ces différentes actions (et des vues associées) côté serveur ;
• le nombre de requêtes AJAX émises depuis la page courante.

En passant la souris sur l'un de ces trois éléments, celui-ci se déploie et affiche un peu plus de détails sur la catégorie d'informations qu'il représente. Par exemple, le premier bloc donne une représentation graphique (une barre horizontale) de la répartition des différents segments du temps de traitement.

En cliquant sur la lettre G, logo de Glimpse, située tout à droite de la barre, cette dernière s'ouvre alors, affichant un panneau assez similaire aux barres d'outils développeur des différents navigateurs Internet.

C'est dans ce panneau que vous trouverez les différents onglets correspondant aux modules Glimpse installés. Par exemple :

• Cache ; pour connaître l'état des différentes clés de cache présentes sur le serveur, leur date d'enregistrement ou encore leur date d'expiration ;
• Execution ; pour visualiser rapidement le chemin de code parcouru lors de l'exécution de la requête (pour l'action principale et toutes les child actions qui auraient été exécutées) - ainsi que tous les filtres qui auraient été attachés à ces actions. L'onglet détaille pour chacun de ces éléments le temps passé en millisecondes, il devient donc aisé de déterminer un goulot d'étranglement dans le traitement de la requête ;
• Routes ; les différentes routes présentes dans la table de routage, mais surtout celle qui a été sélectionnée et pourquoi. L'onglet expose également le temps passé pour évaluer chaque route, ce qui peut se révéler particulièrement utile pour détecter une contrainte un peu trop gourmande.

Les différents onglets présentés dépendent donc des modules Glimpse que vous avez installés. Il est possible d'en ajouter de nouveaux en référençant de nouvelles extensions, d'abord dans votre projet puis dans le fichier web.config.

Ouvrez le fichier web.config d'une application à laquelle Glimpse a été ajouté et vous y trouverez différents nœuds de configuration parmi les suivants.

La déclaration de la section de configuration propre à Glimpse.

<configSections>
    <section name="glimpse" type="Glimpse.Core.Configuration.Section, Glimpse.Core" />
</configSections>
Puis, très important, la déclaration du gestionnaire HTTP (celui utilisé pour activer Glimpse) et d'un module HTTP.
<system.webServer>
  <modules>
    <add name="Glimpse" type="Glimpse.AspNet.HttpModule, Glimpse.AspNet" preCondition="integratedMode" />
  </modules>
  <validation validateIntegratedModeConfiguration="false" />
  <handlers>
    <add name="Glimpse" path="glimpse.axd" verb="GET" type="Glimpse.AspNet.HttpHandler, Glimpse.AspNet" preCondition="integratedMode" />
  </handlers>
</system.webServer>

C'est en fait dans le code du module HTTP que les différents plug-ins de Glimpse ont la possibilité de s'accrocher aux requêtes entrantes et d'activer leurs différents listeners. C'est également au travers de ce module HTTP que ces plug-ins ont la possibilité d'injecter du contenu HTML dans la réponse retournée au client.

Ces premiers éléments représentent la configuration minimale nécessaire pour faire fonctionner Glimpse. Il est possible de rentrer plus loin dans la configuration de Glimpse en utilisant un nœud dédié (celui déclaré par la section de configuration custom citée plus tôt).

<glimpse defaultRuntimePolicy="On" endpointBaseUri="~/Glimpse.axd">
  <!-- 
        Todo
    -->
</glimpse>

C'est donc au travers de ce nœud que nous avons la possibilité de désactiver un onglet de Glimpse présent par défaut, ou d'en ajouter un nouveau. Dans l'exemple suivant, j'ai choisi de retirer l'onglet Routes. Pour trouver le type correspondant, un outil de Reflection sur les DLL de Glimpse ou un petit tour dans la documentation pourra vous aider.

<glimpse defaultRuntimePolicy="On" endpointBaseUri="~/Glimpse.axd">
  <tabs>
    <ignoredTypes>
      <add type="Glimpse.AspNet.Tab.Routes, Glimpse.AspNet"/>
    </ignoredTypes>
  </tabs>
</glimpse>

Glimpse est un outil de débogage à destination des développeurs et éventuellement des agents de production. Il est primordial de faire attention à son activation et à son utilisation dans un environnement de production. En effet, si Glimpse est accessible et utilisé par tous, cela lève automatiquement des problématiques de performances et de sécurité.

Que faire donc ? Déployer votre application Web sans Glimpse ? Ce n'est pas forcément le bon choix à faire. Il peut être intéressant de garder Glimpse actif en production dans certains cas, selon l'URL du client ou l'utilisateur qui se sert de l'application par exemple. Ainsi, il devient assez facile de collecter des informations de performances sur l'environnement de production.

Glimpse dispose d'un mécanisme de règle d'activation. Ainsi, par défaut, il ne fonctionnera que pour les requêtes émises localement sur votre site. Pour pouvoir utiliser Glimpse avec une application hébergée sur un serveur distant, il suffit de désactiver cette règle. Encore une fois, cela se fait au travers du fichier de configuration de votre application et du nœud custom Glimpse.

<glimpse defaultRuntimePolicy="On" endpointBaseUri="~/Glimpse.axd" >
    <runtimePolicies>
        <ignoredTypes>
            <add type="Glimpse.AspNet.Policy.LocalPolicy, Glimpse.AspNet"/>
        </ignoredTypes>
    </runtimePolicies>
</glimpse>

Vous pouvez également créer de nouvelles règles d'activation personnalisées, simplement en implémentant l'interface RuntimePolicy.

public class GlimpseSecurityPolicy : IRuntimePolicy
{
    public RuntimePolicy Execute(IRuntimePolicyContext policyContext)
    {
        var httpContext = policyContext.GetHttpContext();
        if (!httpContext.User.IsInRole("Administrator"))
        {
            return RuntimePolicy.Off;
        }

        return RuntimePolicy.On;
    }

    public RuntimeEvent ExecuteOn
    {
        get { return RuntimeEvent.EndRequest | RuntimeEvent.ExecuteResource; }
    }
}

Glimpse chargera automatiquement la règle en analysant au démarrage de votre application tous les types implémentant l'interface IRuntimePolicy. Vous n'avez donc rien à faire de plus que de compiler et réexécuter votre application pour que cela soit correctement configuré.

En espérant que vous aurez l'occasion d'utiliser Glimpse dans vos applications.

À bientôt.

L'équipe de la rédaction .NET remercie sincèrement Soat de nous avoir autorisés à publier cet article sur Developpez.com. Soat est une société de conseil spécialisée dans l'accompagnement de ses clients, tout au long du cycle de vie de leurs projets et le développement de technologies Java et Web.

Nous remercions également Malick SECK pour la mise au gabarit et Claude Leloup pour sa relecture orthographique.

Vous pouvez donner vos avis sur ce tutoriel dans le forum : 1 commentaire