C'est incroyable à quel point il est facile d'écrire des applications Web à l'aide d'ASP.NET. En raison de cette simplicité, de nombreux développeurs ne prennent pas le temps de structurer leurs applications pour obtenir de meilleures performances. Dans cet article, je couvrirai 10 conseils pour écrire des applications Web hautes performances. Mais je ne limiterais pas ces suggestions aux applications ASP.NET, puisque ces applications ne sont qu'une partie d'une application Web. Cet article n'est pas destiné à être un guide définitif sur l'optimisation des performances des applications Web : un livre entier ne pourrait pas facilement couvrir ce sujet. Considérez cet article comme un excellent point de départ.
Avant de devenir un bourreau de travail, j’aimais l’escalade. Avant toute grande ascension, je commence par examiner attentivement les itinéraires figurant dans les guides et par lire les recommandations des visiteurs précédents. Mais quelle que soit la qualité du guide, vous avez besoin d’une véritable expérience de l’escalade avant de tenter une ascension particulièrement difficile. De même, vous ne pouvez apprendre à écrire des applications Web hautes performances que lorsque vous devez résoudre des problèmes de performances ou exécuter un site à haut débit.
Mon expérience personnelle vient de mon travail en tant que gestionnaire de programme d'infrastructure dans la division ASP.NET chez Microsoft, où j'ai dirigé et géré www.ASP.NET et contribué à l'architecture des serveurs de communauté, l'un des nombreux serveurs bien connus.
Applications ASP.NET (Forums ASP.NET, .Text et nGallery combinés en une seule plateforme). Je suis sûr que certains des conseils qui m'ont aidé vous aideront également.
Vous devriez envisager de diviser votre application en plusieurs couches logiques. Vous avez peut-être entendu le terme architecture physique à 3 niveaux (ou à n niveaux). Il s'agit généralement d'approches architecturales prescrites qui séparent physiquement les fonctionnalités entre les processus et/ou le matériel. Lorsque le système doit s'étendre, du matériel supplémentaire peut être facilement ajouté. Il existe cependant une baisse des performances associée aux sauts de processus et de machine et doit être évitée. Donc, si possible, essayez d’exécuter les pages ASP.NET et leurs composants associés ensemble dans la même application.
En raison de la séparation du code et des limites entre les couches, l'utilisation de services Web ou de services à distance dégradera les performances de 20 % ou plus.
La couche de données est un peu différente car il est généralement préférable d'avoir du matériel dédié à la base de données. Cependant, le coût du transfert du processus vers la base de données reste élevé, c'est pourquoi les performances de la couche de données sont le premier problème à prendre en compte lors de l'optimisation du code.
Avant de vous plonger dans les correctifs de performances pour votre application, assurez-vous d'abord de profiler votre application pour identifier les problèmes spécifiques. Les compteurs de performances clés, tels que ceux représentant le pourcentage de temps requis pour effectuer le garbage collection, sont également utiles pour déterminer où une application passe son temps principal. Cependant, l’endroit où le temps est consacré est souvent très peu intuitif.
Cet article décrit deux types d'améliorations des performances : les optimisations importantes (telles que l'utilisation de la mise en cache ASP.NET) et les petites optimisations qui se répètent. Ces petites optimisations sont parfois particulièrement intéressantes. Vous apportez une petite modification à votre code et vous gagnez beaucoup de temps. Avec des optimisations importantes, vous constaterez peut-être une augmentation importante des performances globales. Avec de petites optimisations, vous ne gagnerez peut-être que quelques millisecondes pour une requête particulière, mais en additionnant toutes les requêtes chaque jour, cela peut constituer une énorme amélioration.
Performances de la couche de données
Lorsqu'il s'agit d'optimiser les performances des applications, il existe un test de jauge que vous pouvez utiliser pour prioriser votre travail : le code accède-t-il à la base de données ? Si oui, à quelle fréquence ? Notez que ce même test peut également être appliqué au code qui utilise des services Web ou du remoting, mais cet article ne les couvre pas.
Si une requête de base de données est nécessaire dans un chemin de code particulier et que vous pensez devoir d'abord optimiser d'autres domaines (comme la manipulation de chaînes), arrêtez puis effectuez ce test de jauge. Si vos problèmes de performances ne sont pas graves, c'est une bonne idée de consacrer du temps à optimiser le temps passé par rapport à la base de données, la quantité de données renvoyées et la fréquence des allers-retours vers et depuis la base de données.
En gardant ces informations générales à l’esprit, examinons dix conseils qui peuvent vous aider à améliorer les performances des applications. Tout d’abord, je parlerai des changements qui pourraient faire la plus grande différence.
Astuce 1 — Renvoyer plusieurs ensembles de résultats
Examinez attentivement le code de votre base de données pour voir s'il existe plusieurs chemins de requête dans la base de données. Chacun de ces allers-retours réduit le nombre de requêtes par seconde que l'application peut traiter. En renvoyant plusieurs jeux de résultats dans une seule requête de base de données, vous pouvez économiser le temps total requis pour communiquer avec la base de données. Dans le même temps, cela rend également le système plus évolutif en réduisant le travail du serveur de base de données dans la gestion des requêtes.
Bien qu'il soit possible d'utiliser du SQL dynamique pour renvoyer plusieurs jeux de résultats, ma méthode préférée consiste à utiliser des procédures stockées. Il y a un débat quant à savoir si la logique métier doit résider dans la procédure stockée, mais je pense qu'il serait préférable que la logique de la procédure stockée puisse contraindre les données renvoyées (en réduisant la taille de l'ensemble de données, en réduisant le temps passé sur le réseau, sans avoir à passer au crible les données de la couche logique), cela doit être privilégié.
Lors du remplissage d'une classe métier fortement typée à l'aide d'une instance SqlCommand et de sa méthode ExecuteReader, vous pouvez déplacer le pointeur du jeu de résultats vers l'avant en appelant NextResult. La figure 1 montre un exemple de session utilisant des classes de types pour remplir plusieurs ArrayLists. Renvoyer uniquement les données dont vous avez besoin à partir de la base de données réduira encore davantage l'allocation de mémoire sur le serveur.
Figure 1 extraction de plusieurs jeux de résultats à partir d'un DataReader
// lit le premier jeu de résultats
reader = command.ExecuteReader();
// lit les données de cet ensemble de résultats
while (reader.Read()) {
fournisseurs.Add (PopulateSupplierFromIDataReader (lecteur));
}
// lit le prochain jeu de résultats
reader.NextResult();
// lit les données de ce deuxième ensemble de résultats
while (reader.Read()) {
products.Add (PopulateProductFromIDataReader (lecteur));
}
Astuce 2 – Accès aux données paginées
ASP.NET DataGrid possède une fonctionnalité intéressante : la prise en charge de la pagination des données. Lorsque la pagination est activée dans DataGrid, un nombre fixe d'enregistrements est affiché à la fois. De plus, une interface utilisateur de pagination est affichée au bas du DataGrid pour faciliter la navigation entre les enregistrements. L'interface utilisateur de pagination vous permet de naviguer vers l'avant et vers l'arrière dans les données affichées et affiche un nombre fixe d'enregistrements à la fois.
Il y a aussi un petit twist. La pagination à l'aide de DataGrid nécessite que toutes les données soient liées à la grille. Par exemple, si votre couche de données doit renvoyer toutes les données, DataGrid filtrera tous les enregistrements affichés en fonction de la page actuelle. Si 100 000 enregistrements sont renvoyés lors de la pagination dans DataGrid, 99 975 enregistrements sont supprimés pour chaque demande (en supposant une taille de page de 25 enregistrements). Lorsque le nombre d'enregistrements augmente, les performances des applications en souffrent car de plus en plus de données doivent être envoyées à chaque requête.
Un excellent moyen d’écrire du code de pagination plus performant consiste à utiliser des procédures stockées. La figure 2 montre un exemple de procédure stockée pour paginer la table Commandes dans la base de données Northwind. Bref, tout ce que vous avez à faire à ce stade est de transmettre l'index de la page et la taille de la page. L'ensemble de résultats approprié est ensuite calculé et renvoyé.
Figure 2 Parcourir le tableau des commandes
CRÉER UNE PROCÉDURE northwind_OrdersPaged
(
@PageIndex entier,
@PageSize entier
)
COMME
COMMENCER
DÉCLARE @PageLowerBound int
DÉCLARE @PageUpperBound int
DECLARE @RowsToReturn int
-- Définissez d'abord le nombre de lignes
SET @RowsToReturn = @PageSize * (@PageIndex + 1)
SET ROWCOUNT @RowsToReturn
-- Définit les limites de la page
FIXER @PageLowerBound = @PageSize * @PageIndex
SET @PageUpperBound = @PageLowerBound + @PageSize + 1
-- Crée une table temporaire pour stocker les résultats sélectionnés
CRÉER UNE TABLE #PageIndex
(
IndexId int IDENTITÉ (1, 1) NON NULLe,
ID de commande int
)
-- Insérer dans la table temporaire
INSÉRER DANS #PageIndex (OrderID)
SÉLECTIONNER
Numéro de commande
DEPUIS
Ordres
COMMANDER PAR
OrderID DESC
-- Nombre total de retours
SELECT COUNT(OrderID) FROM Commandes
-- Renvoie les résultats paginés
SÉLECTIONNER
O.*
DEPUIS
Commandes O,
#PageIndexIndex de pages
OÙ
O.OrderID = PageIndex.OrderID ET
PageIndex.IndexID > @PageLowerBound ET
PageIndex.IndexID < @PageUpperBound
COMMANDER PAR
PageIndex.IndexID
END
Dans le serveur de communauté, nous avons écrit un contrôle de serveur de pagination pour terminer la pagination de toutes les données. Comme vous le verrez, j'utilise le concept abordé dans l'astuce 1 pour renvoyer deux ensembles de résultats à partir d'une procédure stockée : le nombre total d'enregistrements et les données demandées.
Le nombre total d'enregistrements renvoyés peut varier en fonction de la requête exécutée. Par exemple, une clause WHERE peut être utilisée pour contraindre les données renvoyées. Afin de calculer le nombre total de pages affichées dans l'interface utilisateur paginée, vous devez connaître le nombre total d'enregistrements à renvoyer. Par exemple, s'il y a 1 000 000 d'enregistrements au total et que vous souhaitez utiliser une clause WHERE pour le filtrer jusqu'à 1 000 enregistrements, la logique de pagination doit connaître le nombre total d'enregistrements afin d'afficher correctement l'interface utilisateur de pagination.
Astuce 3 - Regroupement de connexions
La configuration d'une connexion TCP entre une application Web et SQL Server peut être une opération très gourmande en ressources. Les développeurs de Microsoft peuvent utiliser le pooling de connexions depuis un certain temps déjà, ce qui leur permet de réutiliser les connexions aux bases de données. Au lieu de configurer une nouvelle connexion TCP pour chaque requête, ils établissent une nouvelle connexion uniquement lorsqu'il n'y a aucune connexion dans le pool de connexions. Lorsque la connexion est fermée, il retourne au pool de connexions où il maintient la connexion à la base de données plutôt que de détruire entièrement la connexion TCP.
Bien sûr, vous devez être prudent si vous développez des connexions qui fuient. Lorsque vous avez fini d'utiliser vos connexions, assurez-vous de les fermer. Pour répéter : peu importe ce que quelqu'un dit à propos du garbage collection dans Microsoft® .NET Framework, veillez à appeler explicitement Close ou Dispose sur une connexion lorsque vous avez fini de l'utiliser. Ne faites pas confiance au Common Language Runtime (CLR) pour effacer et fermer les connexions à votre place à des moments prédéterminés. Bien que le CLR finisse par détruire la classe et force la fermeture de la connexion, il n'y a aucune garantie que le garbage collection de l'objet se produise réellement.
Pour utiliser le pooling de connexions de manière optimale, certaines règles doivent être respectées. Ouvrez d'abord la connexion, effectuez l'opération, puis fermez la connexion. Si vous le devez, ouvrez et fermez la connexion plusieurs fois par requête (de préférence en appliquant le conseil 1), mais ne gardez pas la connexion ouverte tout le temps et transmettez-la en utilisant différentes méthodes. Deuxièmement, utilisez la même chaîne de connexion (et le même ID de thread si vous utilisez l'authentification intégrée). Si vous n'utilisez pas la même chaîne de connexion, par exemple en personnalisant la chaîne de connexion en fonction de l'utilisateur connecté, vous n'obtiendrez pas la même valeur d'optimisation que celle fournie par le pool de connexions. Si vous utilisez l'authentification intégrée et usurpez également l'identité d'un grand nombre d'utilisateurs, l'efficacité du pool de connexions diminuera également considérablement. Les compteurs de performances des données .NET CLR peuvent être utiles lorsque vous essayez de détecter des problèmes de performances liés au regroupement de connexions.
Chaque fois que votre application se connecte à une ressource, telle qu'une base de données exécutée dans un autre processus, vous devez l'optimiser en vous concentrant sur le temps nécessaire pour se connecter à cette ressource, le temps nécessaire pour envoyer ou récupérer des données et le nombre d'allers-retours. L'optimisation de tout type de saut de processus dans votre application est le premier point pour obtenir de meilleures performances.
La couche application contient la logique permettant de se connecter à la couche de données et de transformer les données en instances de classe et en processus métier significatifs. Par exemple, un serveur de communauté, sur lequel vous souhaitez remplir la collection Forums ou Threads, appliquer des règles métier (telles que les autorisations et, plus important encore, y effectuer une logique de mise en cache) ;
Astuce 4 – API de mise en cache ASP.NET
Avant d'écrire une ligne de code d'application, l'une des premières choses à faire est de structurer la couche application pour tirer le meilleur parti des capacités de mise en cache ASP.NET.
Si votre composant doit s'exécuter dans une application ASP.NET, il vous suffit d'inclure une référence à System.Web.dll dans le projet d'application. Lorsque vous devez accéder au cache, utilisez la propriété HttpRuntime.Cache (cet objet est également accessible via Page.Cache et HttpContext.Cache).
Il existe plusieurs règles pour la mise en cache des données. Premièrement, si les données sont susceptibles d’être utilisées plusieurs fois, il s’agit d’une bonne alternative à la mise en cache. Deuxièmement, si les données sont génériques et non spécifiques à une demande ou à un utilisateur spécifique, elles constituent également un bon candidat pour la mise en cache. Si les données sont spécifiques à l'utilisateur ou à la demande, mais ont une longue durée de vie, elles peuvent toujours être mises en cache, mais cela peut ne pas être utilisé très souvent. Troisièmement, une règle souvent négligée est que vous pouvez parfois mettre trop de cache en cache. Généralement sur un ordinateur x86, pour réduire le risque d'erreurs de mémoire insuffisante, vous souhaiterez exécuter des processus avec pas plus de 800 Mo d'octets privés. Le cache doit donc avoir une limite. En d’autres termes, vous pourrez peut-être réutiliser le résultat d’un calcul, mais si ce calcul prend 10 paramètres, vous pourriez essayer de mettre en cache 10 permutations, ce qui pourrait vous causer des ennuis. L'une des demandes les plus courantes de prise en charge d'ASP.NET concerne les erreurs de mémoire insuffisante provoquées par une mise en cache excessive, en particulier pour les ensembles de données volumineux.
La mise en cache possède plusieurs fonctionnalités intéressantes que vous devez connaître. Premièrement, le cache implémente un algorithme utilisé le moins récemment, permettant à ASP.NET de forcer la purge du cache (en supprimant automatiquement les éléments inutilisés du cache) lorsque la mémoire fonctionne moins efficacement. Deuxièmement, le cache prend en charge les dépendances expirées qui peuvent être forcées à expirer. Ces dépendances incluent l'heure, les clés et les fichiers. Le temps est souvent utilisé, mais avec ASP.NET 2.0, un nouveau type d'invalidation plus puissant est introduit : l'invalidation du cache de base de données. Il s'agit de la suppression automatique des éléments du cache lorsque les données de la base de données changent. Pour plus d'informations sur l'invalidation du cache de base de données, consultez la colonne Dino Esposito Cutting Edge dans le magazine MSDN de juillet 2004. Pour comprendre l'architecture du cache, consultez le schéma ci-dessous.
 |
Astuce 6 — Traitement en arrière-plan
Le chemin vers le code doit être aussi rapide que possible, n'est-ce pas ? Il peut arriver que vous ayez l'impression qu'une tâche exécutée à chaque requête ou une fois toutes les n requêtes nécessite beaucoup de ressources. L’envoi d’e-mails ou l’analyse et la validation des données entrantes en sont quelques exemples.
Lors de la dissection des forums ASP.NET 1.0 et de la réarchitecture du contenu qui constitue le serveur de communauté, nous avons constaté que l'ajout de nouveaux chemins de code de publication était très lent. Chaque fois qu'un nouveau message est ajouté, l'application doit d'abord s'assurer qu'il n'y a pas de message en double, puis elle doit analyser le message à l'aide d'un filtre "gros mots", analyser l'émoticône du personnage publié, marquer et indexer le message, et ajouter le publier lorsque cela est demandé Accédez à la file d'attente appropriée, validez la pièce jointe et, lors de la publication finale, envoyez immédiatement une notification par e-mail à tous les abonnés. De toute évidence, cela implique beaucoup de choses.
Après des recherches, il a été constaté que la plupart du temps était consacré à la logique d'indexation et à l'envoi d'e-mails. L'indexation des publications est une opération très fastidieuse et il a été découvert que la fonctionnalité intégrée System.Web.Mail se connecte à un serveur SMYP et envoie ensuite des e-mails en continu. À mesure que le nombre d'abonnés à une publication ou à un sujet particulier augmente, la fonction AddPost prend de plus en plus de temps à s'exécuter.
L'indexation des e-mails n'est pas requise pour chaque demande. Idéalement, nous aimerions regrouper cette opération, en indexant 25 publications à la fois ou en envoyant tous les e-mails toutes les cinq minutes. Nous avons décidé d'utiliser le code que nous avions utilisé précédemment pour prototyper l'invalidation du cache de données qui a été utilisée pour ce qui a abouti dans Visual Studio® 2005.
La classe Timer dans l'espace de noms System.Threading est très utile, mais peu connue dans le .NET Framework, du moins parmi les développeurs Web. Une fois créée, cette classe Timer appellera le rappel spécifié à un intervalle configurable pour un thread dans le ThreadPool. Cela signifie que vous pouvez configurer votre code pour qu'il s'exécute sans requêtes entrantes vers l'application ASP.NET, ce qui est idéal pour le traitement en arrière-plan. Vous pouvez également effectuer des opérations telles que l'indexation ou l'envoi d'e-mails dans ce processus en arrière-plan.
Cependant, cette technologie pose plusieurs problèmes. Si le domaine d'application est désinstallé, cette instance de minuterie cessera de déclencher ses événements. De plus, comme le CLR a une norme stricte concernant le nombre de threads par processus, il peut y avoir des situations où le serveur est fortement chargé et où le minuteur peut ne pas avoir de threads sur lesquels terminer, ce qui entraînera dans une certaine mesure des retards. ASP.NET tente de minimiser les risques que cela se produise en conservant un certain nombre de threads disponibles dans le processus et en n'utilisant qu'une partie du nombre total de threads pour le traitement des requêtes. Cependant, cela peut poser problème si vous effectuez de nombreuses opérations asynchrones.
Il n'y a pas assez de place ici pour ce code, mais vous pouvez télécharger un exemple lisible sur www.rob-howard.net. Découvrez les diapositives et les démos de la présentation Blackbelt TechEd 2004.
Astuce 7 — Mise en cache des sorties de page et serveurs proxy
ASP.NET est votre couche de présentation (ou devrait être votre couche de présentation) ; elle se compose de pages, de contrôles utilisateur, de contrôles serveur (HttpHandlers et HttpModules) et du contenu qu'ils génèrent. Si vous disposez d'une page ASP.NET qui génère une sortie (HTML, XML, images ou toute autre donnée) et que lorsque vous exécutez ce code à chaque requête, il génère la même sortie, vous disposez alors d'un outil qui peut être utilisé pour A excellente alternative à la mise en cache de sortie de page.
Ajoutez cette ligne de contenu en haut de la page <%@ Page OutputCache VaryByParams="none" Duration="60" %>
Vous pouvez générer efficacement une sortie pour cette page une fois, puis la réutiliser plusieurs fois pendant 60 secondes maximum, moment auquel la page sera réexécutée et la sortie sera à nouveau ajoutée au cache ASP.NET. Ce comportement peut également être accompli à l’aide de certaines API programmatiques de bas niveau. Il existe plusieurs paramètres configurables pour la mise en cache des sorties, tels que la propriété VaryByParams que nous venons de mentionner. VaryByParams est simplement demandé, mais vous permet également de spécifier les paramètres HTTP GET ou HTTP POST pour modifier les entrées du cache. Par exemple, définissez simplement VaryByParam="Report" pour mettre en cache la sortie pour default.aspx?Report=1 ou default.aspx?Report=2. Des paramètres supplémentaires peuvent être spécifiés en spécifiant une liste séparée par des points-virgules.
Beaucoup de gens ne savent pas que lorsque la mise en cache de sortie est utilisée, les pages ASP.NET génèrent également des en-têtes HTTP situés en aval du serveur de mise en cache, tels que ceux utilisés par Microsoft Internet Security and Acceleration Server ou Akamai. Après avoir défini l'en-tête du cache HTTP, les documents peuvent être mis en cache sur ces ressources réseau et les demandes des clients peuvent être satisfaites sans retourner au serveur d'origine.
Par conséquent, l’utilisation de la mise en cache de sortie de page ne rendra pas votre application plus efficace, mais elle peut réduire la charge sur le serveur car les technologies de mise en cache en aval mettent le document en cache. Bien sûr, il se peut qu'il s'agisse simplement d'un contenu anonyme ; une fois qu'il sera transmis, vous ne verrez plus jamais ces demandes et vous ne pourrez plus effectuer d'authentification pour en empêcher l'accès.
Astuce 8 - Exécutez IIS 6.0 (utilisez-le simplement pour la mise en cache du noyau)
Si vous n'exécutez pas IIS 6.0 (Windows Server ? 2003), vous passerez à côté de certaines améliorations considérables des performances des serveurs Web Microsoft. Dans l’astuce 7, j’ai discuté de la mise en cache des sorties. Dans IIS 5.0, les requêtes passent par IIS puis dans ASP.NET. En ce qui concerne la mise en cache, le HttpModule dans ASP.NET reçoit la requête et renvoie le contenu du cache.
Si vous utilisez IIS 6.0, vous trouverez une petite fonctionnalité intéressante appelée cache du noyau qui ne nécessite aucune modification du code dans ASP.NET. Lorsqu'une demande de mise en cache de sortie est effectuée par ASP.NET, le cache du noyau IIS reçoit une copie des données mises en cache. Lorsqu'une requête provient d'un pilote réseau, le pilote au niveau du noyau (sans basculement de contexte en mode utilisateur) reçoit la requête, vide les données mises en cache dans la réponse si elles sont mises en cache, puis termine l'exécution. Cela signifie que lorsque vous utilisez la mise en cache en mode noyau avec la mise en cache de sortie IIS et ASP.NET, vous obtiendrez des résultats de performances incroyables. Lors du développement d'ASP.NET dans Visual Studio 2005, j'étais le responsable du programme responsable des performances d'ASP.NET. Les développeurs effectuent le travail spécifique, mais je peux voir tous les rapports qui se produisent chaque jour. Les résultats du cache en mode noyau sont toujours les plus intéressants. La caractéristique la plus courante est que le réseau est inondé de requêtes/réponses, alors qu'IIS ne fonctionne qu'à environ 5 % d'utilisation du processeur. C'est choquant ! Il existe bien sûr d'autres raisons d'utiliser IIS 6.0, mais la mise en cache en mode noyau est la plus évidente.
Astuce 9 — Utilisez la compression Gzip
Bien que l'utilisation de gzip ne soit pas nécessairement une astuce en matière de performances du serveur (car vous pouvez constater une augmentation de l'utilisation du processeur), l'utilisation de la compression gzip peut réduire le nombre d'octets envoyés par le serveur. Cela se traduit par une augmentation perçue de la vitesse des pages et une réduction de l'utilisation de la bande passante. En fonction des données envoyées, de la quantité de compression possible et de la prise en charge ou non du navigateur client (IIS enverra uniquement le contenu compressé au format gzip aux clients prenant en charge la compression gzip, tels qu'Internet Explorer 6.0 et Firefox), votre serveur peut servir Plus de demandes. En fait, presque chaque fois que vous réduisez la quantité de données renvoyées, vous augmentez le nombre de requêtes par seconde.
La compression Gzip est intégrée à IIS 6.0 et ses performances sont bien meilleures que la compression gzip utilisée dans IIS 5.0, ce qui est une bonne nouvelle. Malheureusement, lorsque vous essayez d'activer la compression gzip dans IIS 6.0, vous ne pourrez peut-être pas trouver le paramètre dans la boîte de dialogue Propriétés d'IIS. L'équipe IIS a intégré une excellente fonctionnalité gzip au serveur, mais a oublié d'inclure une interface utilisateur administrative pour l'activer. Pour activer la compression gzip, vous devez fouiller profondément dans les paramètres de configuration XML d'IIS 6.0 (afin de ne pas perdre le cœur). Soit dit en passant, le mérite revient à Scott Forsyth d'OrcsWeb pour m'avoir aidé à soulever ce problème avec le serveur www.asp.net hébergé sur OrcsWeb.
Cet article ne décrira pas les étapes. Veuillez lire l'article de Brad Wilson sur IIS6 Compression. Il existe également un article de la base de connaissances sur l'activation de la compression pour ASPX dans Activer la compression ASPX dans IIS. Notez toutefois qu'en raison de certains détails d'implémentation, la compression dynamique et la mise en cache du noyau ne peuvent pas exister simultanément dans IIS 6.0.
Astuce 10 — État d'affichage du contrôle du serveur
View State est un nom intéressant pour ASP.NET qui stocke certaines données d'état dans des champs de sortie cachés de la page générée. Lorsque la page est renvoyée sur le serveur, celui-ci peut analyser, valider et appliquer ces données d'état d'affichage à l'arborescence de contrôle de la page. Afficher l'état est une fonctionnalité très puissante car elle permet de conserver l'état avec le client et ne nécessite pas de cookies ni de mémoire serveur pour enregistrer cet état. De nombreux contrôles serveur ASP.NET utilisent l'état d'affichage pour conserver les paramètres créés lors des interactions avec des éléments de page, tels que l'enregistrement de la page actuelle affichée lors de la pagination des données.
Cependant, l’utilisation de l’état d’affichage présente également certains inconvénients. Premièrement, cela augmente la charge globale de la page à chaque fois qu’elle est servie ou demandée. Une surcharge supplémentaire se produit également lors de la sérialisation ou de la désérialisation des données d'état d'affichage renvoyées sur le serveur. Enfin, l'état d'affichage augmente l'allocation de mémoire sur le serveur.
Plusieurs contrôles serveur ont tendance à abuser de l’état d’affichage même lorsqu’il n’est pas nécessaire, le plus connu étant DataGrid. Le comportement par défaut de la propriété ViewState est activé, mais vous pouvez le désactiver au niveau du contrôle ou de la page si vous n'en avez pas besoin. Dans le contrôle, définissez simplement la propriété EnableViewState sur false ou définissez-la globalement sur la page à l'aide du paramètre suivant :
＜%@ Page EnableViewState="false" %＞
Si vous ne publiez pas la page ou ne régénérez pas toujours les contrôles de la page à chaque demande, vous devez désactiver l'état d'affichage au niveau de la page.
Je vous ai donné quelques conseils que je trouve utiles lors de l'écriture d'applications ASP.NET hautes performances. Comme je l'ai mentionné plus tôt dans cet article, il s'agit d'un guide préliminaire et non du dernier mot sur les performances d'ASP.NET. (Pour plus d'informations sur l'amélioration des performances des applications ASP.NET, consultez Amélioration des performances ASP.NET.) La meilleure façon de résoudre un problème de performances spécifique ne peut être trouvée que par votre propre expérience. Cependant, ces conseils devraient vous donner de bons conseils pour votre voyage. Dans le développement de logiciels, il existe peu d’absolus ; chaque application est unique.