Conseils relatifs au réglage des performances

1. Désactivez l'état de session s'il n'est pas utilisé : Toutes les applications ou pages n'exigent pas d'état de session par utilisateur. S'il n'est pas nécessaire, désactivez-le complètement. Cette opération peut être aisément effectuée à l'aide d'une directive au niveau de la page, par exemple :

   <%@ Page EnableSessionState="false" %>
   

   Remarque : Si une page nécessite l'accès à des variables de session, mais ne doit pas les créer ou les modifier, affectez à la directive la valeur ReadOnly. L'état de session peut également être désactivé pour les méthodes Web Service XML. Consultez Utilisation d'objets et d'éléments intrinsèques, à la section Services Web XML.

2. Choisissez prudemment votre fournisseur d'état de session : ASP.NET propose trois manières distinctes d'enregistrer les données de session de votre application : état de session in-process, état de session out-of-process en tant que service Windows et état de session out-of-process dans une base de données SQL. Chacun possède ses avantages, mais l'état de session in-process est de loin la solution la plus rapide. Si vous ne stockez que de petites quantités de données volatiles dans l'état de session, utilisez le fournisseur in-process. Les solutions out-of-process sont principalement utiles dans les scénarios de jardins Web et de batterie de serveurs Web ou si les données ne risquent pas d'être perdues en cas de redémarrage du serveur/processus.

3. Évitez les allers-retours excessifs du serveur : L'infrastructure de page Web Forms est l'une des meilleures fonctionnalités de ASP.NET, car elle réduit considérablement la quantité de code à écrire pour accomplir une tâche. L'accès par programme à des éléments de page à l'aide de contrôles serveur et le modèle de gestion des événements de publication sont probablement les fonctionnalités qui permettent de gagner le plus de temps. Cependant, ces fonctionnalités peuvent être bien ou mal utilisées et il est important de savoir quand il est judicieux d'y recourir.

   Une application ne doit généralement effectuer un aller-retour au serveur que pour récupérer ou stocker des données. La plupart des manipulations de données peuvent se produire sur le client, entre les allers-retours. Par exemple, la validation d'entrées de formulaires peut souvent se produire sur le client, avant que l'utilisateur envoie des données. En général, si vous ne devez pas relayer d'informations au serveur, vous ne devez pas effectuer un aller-retour jusqu'à celui-ci.

   Si vous écrivez vos propres contrôles serveur, pensez à leur faire restituer le code côté client pour les navigateurs de haut niveau (avec fonction ECMAScript). En employant des contrôles «intelligents», vous pouvez réduire considérablement le nombre d'accès superflus à votre serveur Web.

4. Utilisez Page.IsPostback pour éviter toute tâche supplémentaire lors d'un aller-retour : Si vous gérez les publications de contrôles serveur, vous devez souvent exécuter, lors de la première demande de la page, un code différent de celui utilisé pour l'aller-retour lorsqu'un événement est déclenché. Si vous activez la propriété Page.IsPostBack, votre code peut s'exécuter de manière conditionnelle, selon qu'il existe ou non une demande initiale pour la page ou une réponse à un événement de contrôle serveur. Cela peut sembler évident, mais en pratique, il est possible d'oublier cette activation sans modifier le comportement de la page. Par exemple :

   <script language="C#" runat="server"> public DataSet ds; ... void Page_Load(Object sender, EventArgs e) { // ...set up a connection and command here... if (!Page.IsPostBack) { String query = "select * from Authors where FirstName like '%JUSTIN%'"; myCommand.Fill(ds, "Authors"); myDataGrid.DataBind(); } } void Button_Click(Object sender, EventArgs e) { String query = "select * from Authors where FirstName like '%BRAD%'"; myCommand.Fill(ds, "Authors"); myDataGrid.DataBind(); } </script> <form runat="server"> <asp:datagrid datasource='<%# ds.DefaultView % >' runat="server"/><br> <asp:button onclick="Button_Click" runat="server"/> </form> <script language="VB" runat="server"> Public ds As DataSet ... Sub Page_Load(sender As Object, e As EventArgs) ' ...set up a connection and command here... If Not (Page.IsPostBack) Dim query As String = "select * from Authors where FirstName like '%JUSTIN%'" myCommand.Fill(ds, "Authors") myDataGrid.DataBind() End If End Sub Sub Button_Click(sender As Object, e As EventArgs) Dim query As String = "select * from Authors where FirstName like '%BRAD%'" myCommand.Fill(ds, "Authors") myDataGrid.DataBind() End Sub </script> <form runat="server"> <asp:datagrid datasource='<%# ds. Tables["Authors"].DefaultView %>' runat="server"/><br> <asp:button onclick ="Button_Click" runat="server"/> </form> <script language="JScript" runat="server"> public var ds:DataSet; ... function Page_Load(sender:Object, e:EventArgs) : void { // ...set up a connection and command here... if (!Page.IsPostBack) { var query:String = "select * from Authors where FirstName like '%JUSTIN%'"; myCommand.Fill(ds, "Authors"); myDataGrid.DataBind(); } } function Button_Click(sender: Object, e:EventArgs) : void { var query:String = "select * from Authors where FirstName like '%BRAD%'"; myCommand.Fill(ds, "Authors"); myDataGrid.DataBind(); } </script> <form runat="server"> <asp:datagrid datasource='<%# ds.DefaultView % >' runat="server"/><br> <asp:button onclick= "Button_Click" runat="server"/> </form> C# VB JScript

   L'événement Page_Load s'exécute à chaque demande. Par conséquent, nous avons activé Page.IsPostBack afin que la première demande ne s'exécute pas lorsque nous traitons la publication d'événement Button_Click. Remarquez que même sans cette activation, notre page se comporterait de manière identique, car la liaison provenant de la première demande serait annulée par l'appel à DataBind dans le gestionnaire d'événements. Gardez à l'esprit que cette amélioration des performances peut être facilement oubliée lors de l'écriture de vos pages.

5. Utilisez les contrôles serveur avec parcimonie et de manière appropriée : Même s'ils sont extrêmement conviviaux, les contrôles serveur ne constituent pas toujours le meilleur choix. Dans de nombreuses situations, une simple substitution de rendu ou de liaison de données a le même effet. Par exemple :

   <script language="C#" runat="server"> public String imagePath; void Page_Load(Object sender, EventArgs e) { //...retrieve data for imagePath here... DataBind(); } </script> <%-- the span and img server controls are unecessary...--%> The path to the image is: <span innerhtml='<%# imagePath %>' runat="server"/><br> <img src='<%# imagePath %>' runat="server"/> <br><br> <%-- use databinding to substitute literals instead...--%> The path to the image is: <%# imagePath %><br> <img src='<%# imagePath %>' /> <br><br> <%-- or a simple rendering expression...--%> The path to the image is: <%= imagePath %><br> <img src='<%= imagePath %>' /> <script language="VB" runat="server"> Public imagePath As String Sub Page_Load(sender As Object, e As EventArgs) '...retrieve data for imagePath here... DataBind() End Sub </script> <%--the span and img server controls are unecessary...--%> The path to the image is: <span innerhtml ='<%# imagePath %>' runat="server"/><br> <img src='<%# imagePath %>' runat="server"/> <br><br> <%-- use databinding to substitute literals instead...--%> The path to the image is: <%# imagePath %><br> <img src='<%# imagePath %>' /> <br><br> <%-- or a simple rendering expression...--%> The path to the image is: <%= imagePath %><br> <img src='<%= imagePath %>' /> <script language="JScript" runat="server"> public var imagePath:String; function Page_Load(sender: Object, e:EventArgs) : void { //...retrieve data for imagePath here... DataBind(); } </script> <%-- the span and img server controls are unecessary...--%> The path to the image is: <span innerhtml='<%# imagePath %>' runat="server"/><br> <img src='<%# imagePath %>' runat="server"/> <br><br> <%-- use databinding to substitute literals instead...--%> The path to the image is: <%# imagePath %><br> <img src='<%# imagePath %>' /> <br><br> <%-- or a simple rendering expression...--%> The path to the image is: <%= imagePath %><br> <img src='<%= imagePath %>' /> C# VB JScript

   Dans cet exemple, un contrôle serveur n'est pas nécessaire pour substituer des valeurs dans le code HTML obtenu renvoyé au client. Dans de nombreux autres cas, cette technique fonctionne correctement, même dans les modèles de contrôles serveur. Cependant, si vous souhaitez manipuler par programme les propriétés du contrôle, traitez les événements à partir de celui-ci ou profitez de sa préservation d'état. Dans ce cas, un contrôle serveur est approprié. Il est conseillé d'examiner votre utilisation des contrôles serveur et de rechercher le code susceptible d'être optimisé.

6. Évitez tout état d'affichage de contrôle serveur excessif : La gestion d'état automatique est une fonctionnalité permettant aux contrôles serveur de remplir à nouveau leurs valeurs lors d'un aller-retour, sans nécessité d'écrire du code. Cependant, cette fonctionnalité n'est pas libre, car l'état d'un contrôle est passé au serveur et retourné par celui-ci dans un champ de formulaire masqué. Il est important de savoir quand ViewState vous est utile ou quand ce n'est pas le cas. Par exemple, si vous liez un contrôle à des données lors de chaque aller-retour (comme dans l'exemple de grille de données du conseil 4), il n'est pas nécessaire que le contrôle gère son état d'affichage, car vous éliminez de toute façon les données éventuellement remplies à nouveau.

   Par défaut, ViewState est activé pour tous les contrôles serveur. Pour le désactiver, affectez à la propriété MaintainState du contrôle la valeur false, comme dans l'exemple suivant :

   <asp:datagrid EnableViewState="false" 
   datasource="..." runat="server"/>
   

   Vous pouvez également désactiver ViewState au niveau de la page. Cette opération est utile si vous n'effectuez aucune publication à partir d'une page, comme dans l'exemple suivant :

   <%@ Page EnableViewState="false" %>
   

   Remarquez que cet attribut est également pris en charge par la directive User Control. Pour analyser la quantité d'états d'affichage utilisée par les contrôles serveur sur votre page, activez le traçage et observez la colonne État d'affichage (View State) du tableau Hiérarchie des contrôles (Control Hierarchy). Pour plus d'informations sur la fonctionnalité de traçage et son activation, consultez la section Journalisation du traçage au niveau de l'application.

7. Utilisez Response.Write pour la concaténation de chaînes : Utilisez la méthode HttpResponse.Write dans vos pages ou contrôles utilisateur pour concaténer des chaînes. Cette méthode offre de puissants services de mise en mémoire tampon et de concaténation. Toutefois, si vous êtes amené à effectuer des concaténations étendues, la technique illustrée plus bas et consistant à utiliser des appels multiples à Response.Write, est plus rapide que la technique de concaténation d'une chaîne à l'aide d'un appel unique à la méthode Response.Write.

   Response.Write("a"); Response.Write(myString); Response.Write("b"); Response.Write(myObj.ToString()); Response.Write("c"); Response.Write(myString2); Response.Write("d"); Response.Write("a") Response.Write(myString) Response.Write("b") Response.Write(myObj.ToString()) Response.Write("c") Response.Write(myString2) Response.Write("d") Response.Write("a"); Response.Write(myString); Response.Write("b"); Response.Write(myObj.ToString()); Response.Write("c"); Response.Write(myString2); Response.Write("d"); C# VB JScript

8. Ne vous basez pas sur des exceptions dans votre code : Les exceptions sont extrêmement coûteuses et ne doivent apparaître que rarement dans votre code. N'utilisez jamais d'exceptions en vue de contrôler le déroulement normal du programme. Il est possible de détecter dans le code une condition entraînant une exception. Effectuez cette opération plutôt que d'attendre d'intercepter l'exception avant de gérer la condition. Les scénarios les plus courants sont les suivants : recherche de valeurs null, assignation à une chaîne qui sera analysée dans une valeur numérique ou vérification des valeurs spécifiques avant l'exécution d'opérations mathématiques. Par exemple :

   // Consider changing this: try { result = 100 / num; } catch (Exception e) { result = 0; } // To this: if (num != 0) result = 100 / num; else result = 0; ' Consider changing this: Try result = 100 / num Catch (e As Exception) result = 0 End Try // To this: If Not (num = 0) result = 100 / num Else result = 0 End If // Consider changing this: try { result = 100 / num; } catch (e:Exception) { result = 0; } // To this: if (num != 0) result = 100 / num; else result = 0; C# VB JScript

9. Utilisez la liaison anticipée dans du code Visual Basic ou JScript : Visual Basic, VBScript et JScript ont l'avantage de ne pas posséder de type. Les variables peuvent être créées simplement en les utilisant et ne nécessitent aucune déclaration de type explicite. Lors de l'assignation d'un type à un autre, des conversions s'exécutent aussi automatiquement. Il peut s'agir d'un avantage ou d'un inconvénient, car la liaison tardive est un confort extrêmement coûteux en termes de performances.

   Le langage Visual Basic prend maintenant en charge la programmation de type sécurisé à l'aide d'une directive de compilation Option Strict spéciale. Par souci de compatibilité ascendante, ASP.NET n'active pas Option Strict par défaut. Cependant, afin d'optimiser les performances, vous pouvez activer Option Strict pour vos pages à l'aide d'un attribut Strict sur la page ou dans la directive Control :

   <%@ Page Language="VB" Strict="true" %>
   
   <%
   
   Dim B
   Dim C As String
   
   ' This causes a compiler error:
   A = "Hello"
   
   ' This causes a compiler error:
   B = "World"
   
   ' This does not:
   C = "!!!!!!"
   
   ' But this does:
   C = 0
   
   %>
   

   JScript prend également en charge la programmation sans type, même si elle ne propose aucune directive pour forcer la liaison anticipée. Une variable est une variable à liaison tardive si :

   • elle est déclarée de manière explicite comme un objet ;
   • il s'agit d'un champ d'une classe sans déclaration de type ;
   • il s'agit d'un membre de fonction/méthode privé sans déclaration de type explicite. En outre, le type ne peut pas être déduit de son utilisation.

   La dernière distinction est compliquée. Le compilateur JScript fonctionne de manière optimale s'il peut déterminer le type en se basant sur le mode d'utilisation d'une variable. Dans l'exemple suivant, la variable A est à liaison anticipée, mais la variable B est à liaison tardive :

   var A;
   var B;
   
   A = "Hello";
   B = "World";
   B = 0;
   

   Pour optimiser les performances, déclarez vos variables JScript comme possédant un type, par exemple « var A : String ».

10. Migrez les composants COM qui exécutent de nombreux appels vers le code managé : le .NET Framework facilite considérablement l'interaction avec les composants COM traditionnels. Vous pouvez ainsi profiter de la nouvelle plate-forme tout en conservant votre code existant. Cependant, dans certaines circonstances, le coût en termes de performances de la conservation de vos anciens composants est supérieur au coût de leur migration vers le code managé. Chaque situation est unique et la meilleure manière de décider des modifications à apporter consiste à mesurer les performances du site. En général, cependant, l'impact de l'interopérabilité COM sur les performances est proportionnel au nombre d'appels de fonctions lancés ou à la quantité de données marshalées du code non managé vers le code managé. Un composant nécessitant un grand volume d'appels avec lesquels interagir est appelé « bavard », à cause du nombre de communications entre les couches. Envisagez de migrer ces composants vers un code complètement managé afin de bénéficier de toutes les améliorations de performances fournies par la plate-forme .NET. Vous pouvez également envisager de remodeler votre composant pour qu'il nécessite moins d'appels ou qu'il marshale davantage de données simultanément.

11. Utilisez des procédures stockées SQL pour l'accès aux données : De toutes les méthodes d'accès aux données fournies par le .NET Framework, l'accès aux données basé sur SQL constitue le meilleur choix pour la génération d'applications Web évolutives assurant des performances optimales. Lorsque vous utilisez le fournisseur SQL managé, vous pouvez augmenter davantage les performances en employant des procédures stockées compilées plutôt que des requêtes ad hoc. Pour obtenir un exemple illustrant l'utilisation de procédures stockées SQL, consultez la section Accès aux données côté serveur de ce didacticiel.

12. Utilisez SqlDataReader pour un curseur de données en avant et en lecture seule : Un objet SqlDataReader fournit un curseur en avant et en lecture seule sur les données extraites d'une base de données SQL. Si son utilisation est possible dans votre scénario, SqlDataReader offre de meilleurs résultats qu'un DataSet. Comme SqlDataReader prend en charge l'interface IEnumerable, vous pouvez même lier des contrôles serveur. Pour obtenir un exemple illustrant l'utilisation de SqlDataReader, consultez la section Accès aux données côté serveur de ce didacticiel.

13. Mettez les données et la sortie en cache chaque fois que cela est possible : le modèle de programmation de ASP.NET fournit un mécanisme simple permettant de mettre la sortie ou les données de la page en cache lorsqu'elles ne doivent pas être calculées de manière dynamique pour chaque demande. Vous pouvez concevoir vos pages en tenant compte de la mise en cache afin d'optimiser les parties de votre application censées enregistrer le trafic le plus important. Plus que toute fonctionnalité du .NET Framework, l'utilisation appropriée de la mise en cache peut améliorer, voire multiplier, les performances de votre site. Pour plus d'informations sur l'utilisation de la mise en cache, consultez la section Vue d'ensemble de la mise en cache de ce didacticiel.

14. Activez le jardinage Web pour les ordinateurs multiprocesseurs : Le modèle de processus de ASP.NET permet l'évolutivité sur des ordinateurs multiprocesseurs en répartissant le travail entre plusieurs processus (un par UC), chacun ayant une affinité avec le processeur de son UC. Cette technique porte le nom de jardinage Web et permet d'améliorer considérablement les performances de certaines applications. Pour savoir comment activer le jardinage Web, consultez la section Utilisation du modèle de processus.

15. N'oubliez pas de désactiver le mode débogage : La section <compilation> de la configuration ASP.NET contrôle si une application est compilée en mode débogage. Le mode débogage altère considérablement les performances. Veillez à toujours désactiver le mode débogage avant de déployer une application de production ou de mesurer les performances. Pour plus d'informations sur le mode débogage, consultez la section Débogueur du Kit de développement Microsoft .NET Framework SDK.