Les 10 meilleures façons d'améliorer les performances des applications ASP.Net
Auteur：Eve Cole
Date de mise à jour：2009-06-30 15:49:49
Cet article traite de :
Mythes courants sur l'amélioration des performances des applications asp.net Conseils utiles pour améliorer les performances des applications asp.net
Recommandations pour l'exploitation des bases de données avec les applications Asp.net
Mise en cache et traitement en arrière-plan dans Asp.net
De nos jours, écrire une application Web ASP.NET est devenu très simple et de nombreux programmeurs ne sont pas disposés à passer du temps à créer une application offrant de bonnes performances. Cet article abordera les dix principales façons d'améliorer les performances des applications Web. Je ne limiterai pas ma discussion aux seules applications ASP.NET, car elles ne constituent qu'un sous-ensemble d'applications Web. Cet article ne peut pas non plus fournir un guide complet pour améliorer les performances des applications Web, car cela nécessiterait la longueur d'un livre. Cet article fournit uniquement un bon point de départ pour améliorer les performances des applications Web. (Il ne reste plus qu'à étudier lentement par nous-mêmes).
En dehors du travail, je fais souvent de l'escalade. Avant chaque escalade, je passe en revue la carte des itinéraires d'escalade et je lis les conseils d'anciens grimpeurs à succès. Parce que nous avons besoin de leur expérience réussie. De même, lorsque vous devez modifier un programme présentant des problèmes de performances ou développer un site Web performant, vous devez également apprendre à écrire une application Web performante.
Mon expérience personnelle vient principalement de mon travail en tant que gestionnaire de programme dans le groupe asp.net de Microsoft, de l'exécution et de la gestion du site Web www.asp.net et de mon aide au développement de Community Server (qui est une version intégrée et mise à niveau des forums asp.net). , .Text et nGallery). Je pense que ces expériences peuvent m'aider.
Vous pourriez penser à diviser votre application en différentes couches logiques. Vous avez peut-être également entendu parler de l'architecture physique à trois niveaux ou de l'architecture à N niveaux, qui est le modèle d'architecture le plus couramment utilisé. Elle attribue physiquement différentes fonctions de programme à divers matériels pour leur exécution. De cette façon, si nous voulons améliorer les performances de l’application, l’ajout de matériel peut atteindre l’objectif. Il va de soi que cette méthode peut améliorer les performances de l’application, mais nous devons éviter d’utiliser cette méthode. Par conséquent, dans la mesure du possible, nous devons placer la page ASP.NET et les composants qu'elle utilise dans une application.
En raison du déploiement distribué et de l'utilisation de services Web ou du remoting, cela réduira les performances de l'application de 20 % ou plus.
La couche de données est un peu différente. Il est préférable de la déployer indépendamment et d'utiliser un matériel distinct pour l'exécuter. Malgré cela, la base de données reste le goulot d’étranglement des performances des applications. Par conséquent, lorsque vous souhaitez optimiser votre programme, la première chose qui vous vient à l’esprit doit être l’optimisation de la couche de données.
Avant de modifier une zone de votre application qui pose des problèmes de performances, vous devez vous assurer que le programme à l'origine du problème semble précis. Les profileurs de performances sont très utiles pour déterminer où cela prend combien de temps dans votre application. Ce sont des endroits que nous ne pouvons pas ressentir intuitivement.
Cet article traite de deux types d'optimisations de performances : l'une concerne les grandes optimisations de performances (grandes optimisations), telles que l'utilisation du cache d'asp.net ; l'autre concerne les petites optimisations de performances (minuscules optimisations). De petites optimisations de performances peuvent parfois s’avérer très utiles. Vous apportez une petite modification à votre code et l'appelez mille ou dix mille fois à la fois. Faites une grande optimisation des performances et vous constaterez une grande amélioration de la vitesse de votre application. Une petite optimisation des performances ne peut améliorer qu'une microseconde par requête, mais si le nombre de requêtes par jour est important, l'application bénéficiera d'une amélioration significative des performances.
Performances de la couche de données
Lorsque vous souhaitez optimiser les performances d'une application, vous pouvez travailler dans l'ordre suivant : Votre code a-t-il besoin d'accéder à la base de données ? Si oui, à quelle fréquence faut-il accéder à la base de données ? De même, cette méthode de test peut également être utilisée dans le code de programme qui utilise des services Web ou du remoting. Cet article n'abordera pas la question de l'optimisation des programmes à l'aide des services Web et du Remoting.
S'il y a une requête dans votre code qui doit accéder à la base de données et que vous voyez du code qui implémente la même fonction ailleurs, vous devez d'abord l'optimiser. Modifiez, améliorez et continuez les tests. Sauf si vous rencontrez un problème de performances très important, il est préférable de consacrer votre temps à l'optimisation des requêtes, à la connexion à la base de données, au renvoi de la taille de l'ensemble de données et au temps nécessaire pour renvoyer une requête.
Sur la base du résumé de l'expérience, examinons dix expériences qui peuvent vous aider à améliorer les performances de votre application. Je les expliquerai par ordre décroissant de la plus grande à la plus petite en termes d'amélioration de l'efficacité.
1. Renvoyez plusieurs ensembles de données
Vérifiez le code d'accès à votre base de données pour voir si des requêtes reviennent plusieurs fois. Chaque aller-retour réduit le nombre de requêtes par seconde auxquelles votre application peut répondre. En renvoyant plusieurs jeux de résultats dans une seule requête de base de données, vous réduisez le temps nécessaire à la communication avec la base de données, rendez votre système évolutif et réduisez la charge de travail sur le serveur de base de données pour répondre aux requêtes.
Si vous utilisez des instructions SQL dynamiques pour renvoyer plusieurs ensembles de données, je vous recommande d'utiliser des procédures stockées plutôt que des instructions SQL dynamiques. La question de savoir s'il faut écrire une logique métier dans des procédures stockées est un peu controversée. Mais je pense qu'écrire une logique métier dans des procédures stockées peut limiter la taille du jeu de résultats renvoyé, réduire le trafic de données réseau et éliminer le besoin de filtrer les données au niveau de la couche logique.
Utilisez la méthode ExecuteReader de l'objet SqlCommand pour renvoyer un objet métier fortement typé, puis appelez la méthode NextResult pour déplacer le pointeur d'ensemble de données afin de localiser l'ensemble de données. L'exemple 1 montre un exemple de renvoi de plusieurs objets ArrayList fortement typés. Renvoyer uniquement les données dont vous avez besoin à partir de la base de données peut réduire considérablement la consommation de mémoire de votre serveur.
2. Pagination des données
ASPIC. Le DataGrid de NET possède une fonctionnalité très utile : la pagination. Si le DataGrid permet la pagination, il ne téléchargera les données d'une certaine page qu'à un certain moment. De plus, il dispose d'une barre de navigation pour la pagination des données, qui vous permet de choisir de parcourir une certaine page et de télécharger seulement une page de. données à la fois.
Mais cela présente un petit inconvénient, c'est-à-dire que vous devez lier toutes les données au DataGrid. En d'autres termes, votre couche de données doit renvoyer toutes les données, puis DataGrid filtre les données requises par la page actuelle et les affiche. S'il existe un ensemble de résultats de 10 000 enregistrements qui doivent être paginés à l'aide du DataGrid, en supposant que le DataGrid n'affiche que 25 éléments de données par page, cela signifie que 9 975 éléments de données seront supprimés dans chaque requête. Chaque requête doit renvoyer un ensemble de données aussi volumineux, ce qui a un impact énorme sur les performances de l'application.
Une bonne solution consiste à écrire une procédure stockée de pagination. L'exemple 2 est une procédure stockée de pagination pour la table des commandes de la base de données Northwind. Il vous suffit de transmettre le numéro de page actuelle et le nombre d'éléments affichés sur chaque page, et la procédure stockée renverra les résultats correspondants.
Côté serveur, j'ai spécialement écrit un contrôle de pagination pour gérer la pagination des données. Ici, j'ai utilisé la première méthode et j'ai renvoyé deux ensembles de résultats dans une procédure stockée : le nombre total d'enregistrements de données et l'ensemble de résultats requis.
Le nombre total d'enregistrements renvoyés dépend de la requête en cours d'exécution ; par exemple, une condition Where peut limiter la taille du jeu de résultats renvoyé. Étant donné que le nombre total de pages doit être calculé en fonction de la taille des enregistrements de l'ensemble de données dans l'interface de pagination, le nombre d'enregistrements dans l'ensemble de résultats doit être renvoyé. Par exemple, s'il y a 1 000 000 d'enregistrements au total, si vous utilisez la condition Where, vous pouvez filtrer pour renvoyer uniquement 1 000 enregistrements. La logique de pagination de la procédure stockée doit savoir renvoyer les données qui doivent être affichées.
3. Pool de connexions
L'utilisation de TCP pour connecter votre application à la base de données coûte cher (et prend du temps). Les développeurs Microsoft peuvent utiliser des pools de connexions pour réutiliser les connexions à la base de données. Plutôt que d'utiliser TCP pour se connecter à la base de données pour chaque requête, le pool de connexions crée une nouvelle connexion TCP uniquement lorsqu'il n'existe aucune connexion valide. Lorsqu'une connexion est fermée, elle sera placée dans le pool et maintiendra toujours une connexion à la base de données, réduisant ainsi le nombre de connexions TCP à la base de données.
Bien entendu, vous devez faire attention aux connexions que vous avez oublié de fermer. Vous devez le fermer immédiatement après chaque utilisation. Ce que je tiens à souligner est le suivant : peu importe ce que quelqu'un dit, le GC (garbage collector) du framework .net appellera toujours la méthode Close ou Dispose de l'objet de connexion pour fermer explicitement votre connexion une fois que vous aurez fini d'utiliser l'objet de connexion. Ne vous attendez pas à ce que le CLR ferme la connexion dans le délai que vous imaginez. Même si le CLR finira par détruire l'objet et fermer la connexion, nous ne savons pas quand il fera ces choses.
Pour utiliser l'optimisation du pool de connexions, il existe deux règles : tout d'abord, ouvrez la connexion, traitez les données, puis fermez la connexion. Si vous devez ouvrir ou fermer la connexion plusieurs fois par requête, c'est mieux que d'ouvrir une connexion secondaire tout le temps et de la transmettre à chaque méthode. Deuxièmement, utilisez la même chaîne de connexion (ou le même ID utilisateur, lorsque vous utilisez l'authentification intégrée). Si vous n'utilisez pas la même chaîne de connexion, par exemple si vous utilisez une chaîne de connexion basée sur l'utilisateur connecté, cela ne profitera pas des fonctionnalités d'optimisation du pool de connexions. Si vous utilisez des arguments intégrés, vous ne pouvez pas profiter pleinement de la fonction d'optimisation du pool de connexions car les utilisateurs sont nombreux. .NET CLR fournit un compteur de performances des données, ce qui est très utile lorsque nous devons suivre les caractéristiques de performances des programmes, y compris le suivi du pool de connexions.
Chaque fois que votre application se connecte à une ressource sur une autre machine, telle qu'une base de données, vous devez vous concentrer sur l'optimisation du temps nécessaire pour vous connecter à la ressource, du temps nécessaire pour recevoir et envoyer des données, ainsi que du nombre de fois que vous revenez en arrière. . L'optimisation de chaque saut de processus dans votre application est le point de départ pour améliorer les performances de votre application.
La couche application contient la logique pour se connecter à la couche de données, transférer les données vers les instances des classes correspondantes et effectuer le traitement métier. Par exemple, dans Community Server, vous devez assembler une collection Forums ou Threads, puis appliquer une logique métier, telle que l'autorisation. Plus important encore, vous devez compléter la logique de mise en cache ici.
4. ASP. API de cache NET
Avant d'écrire une application, la première chose à faire est de faire en sorte que l'application optimise l'utilisation des capacités de mise en cache d'ASP.NET.
Si votre composant doit être exécuté dans une application Asp.net, il vous suffit de référencer System.Web.dll dans votre projet. Utilisez ensuite la propriété HttpRuntime.Cache pour accéder au cache (il est également accessible via Page.Cache ou HttpContext.Cache).
Il existe plusieurs règles pour la mise en cache des données. Premièrement, les données peuvent être utilisées fréquemment et ces données peuvent être mises en cache. Deuxièmement, la fréquence d'accès aux données est très élevée, ou la fréquence d'accès à une donnée n'est pas élevée, mais son cycle de vie est très long. Il est préférable de mettre ces données en cache. Le troisième est un problème qui est souvent ignoré. Parfois, nous mettons trop de données en cache. Généralement sur une machine X86, si les données que vous souhaitez mettre en cache dépassent 800 Mo, une erreur de dépassement de mémoire se produira. Le cache est donc limité. En d'autres termes, vous devez estimer la taille de l'ensemble de cache et limiter la taille de l'ensemble de cache à moins de 10, sinon cela pourrait entraîner des problèmes. Dans Asp.net, si le cache est trop volumineux, une erreur de dépassement de mémoire sera signalée, surtout si un objet DataSet volumineux est mis en cache.
Voici quelques mécanismes de mise en cache importants que vous devez comprendre. Premièrement, le cache implémente le principe du « le plus récemment utilisé » (un algorithme le moins récemment utilisé). Lorsqu'il y a peu de caches, il effacera automatiquement de force les caches inutiles. Deuxièmement, le principe des « dépendances conditionnelles » force l'élimination (dépendances d'expiration), les conditions pouvant être le temps, les mots-clés et les fichiers. Le temps en tant que condition est le plus couramment utilisé. Une condition plus forte est ajoutée dans asp.net2.0, qui est la condition de base de données. Lorsque les données de la base de données changent, le cache est forcé d'être vidé. Pour un examen plus approfondi des dépendances conditionnelles des bases de données, consultez la rubrique Cutting Edge de Dino Esposito dans le numéro de juillet 2004 de MSDN Magazine. L'architecture du cache d'Asp.net est présentée dans la figure ci-dessous :
5. Mise en cache de pré-demande
Plus tôt, j'ai mentionné que même si nous n'apportons qu'une petite amélioration des performances à certains endroits, nous pouvons obtenir une grande amélioration des performances. J'aime vraiment utiliser la mise en cache de pré-requête pour améliorer les performances du programme.
Bien que l'API Cache soit conçue pour enregistrer les données pendant une certaine période de temps, le cache de pré-requête n'enregistre le contenu d'une certaine requête que pendant une certaine période de temps. Si la fréquence d'accès d'une certaine demande est élevée et que cette demande n'a besoin d'extraire, d'appliquer, de modifier ou de mettre à jour les données qu'une seule fois. Ensuite, la demande peut être pré-mise en cache. Donnons un exemple pour illustrer.
Dans l'application CS Forum, le contrôle serveur de chaque page nécessite des données personnalisées pour déterminer son habillage, pour déterminer la feuille de style à utiliser et d'autres éléments personnalisés. Certaines données ici peuvent devoir être enregistrées pendant une longue période, mais parfois non. Par exemple, les données d'apparence d'un contrôle ne doivent être appliquées qu'une seule fois et peuvent être utilisées à tout moment.
Pour implémenter la mise en cache de pré-demande, utilisez la classe HttpContext d'Asp.net. Une instance de la classe HttpContext est créée à chaque requête et est accessible via la propriété HttpContext.Current n'importe où pendant la requête. La classe HttpContext possède une propriété de collection Items, et tous les objets et données sont ajoutés à cette collection et mis en cache lors de la requête. Tout comme vous utilisez Cache pour mettre en cache les données fréquemment consultées, vous pouvez utiliser HttpContext.Items pour mettre en cache les données de base utilisées dans chaque requête. La logique derrière cela est simple : nous ajoutons une donnée à HttpContext.Items, puis lisons les données à partir de celle-ci.
6. Traitement en arrière-plan
Avec la méthode ci-dessus, votre application devrait s’exécuter très rapidement, n’est-ce pas ? Mais à un moment donné, une tâche très chronophage peut être effectuée lors d'une requête dans le programme. Comme envoyer des e-mails ou vérifier l'exactitude des données soumises, etc.
Lorsque nous avons intégré asp.net Forums 1.0 dans CS, nous avons constaté que la soumission d'un nouveau message serait très lente. A chaque fois qu'une nouvelle publication est ajoutée, l'application doit d'abord vérifier si la publication est un doublon, puis la filtrer à l'aide du filtre "mauvais mot", vérifier le code de la pièce jointe de l'image, indexer la publication, et l'ajouter à la file d'attente appropriée, valider. sa pièce jointe, et enfin, envoyer l'email vers la boîte mail de son abonné. Évidemment, cela représente beaucoup de travail.
Le résultat est qu’il passe beaucoup de temps à indexer et à envoyer des emails. L'indexation des publications est une opération qui prend du temps, et l'envoi d'e-mails aux abonnés nécessite de se connecter au service SMTP puis d'envoyer un e-mail à chaque abonné. À mesure que le nombre d'abonnés augmente, le temps nécessaire pour envoyer des e-mails augmentera.
L'indexation et l'envoi d'emails n'ont pas besoin d'être déclenchés à chaque demande. Idéalement, nous aimerions traiter ces opérations par lots, en envoyant seulement 25 emails à la fois ou tous les nouveaux emails envoyés toutes les 5 minutes. Nous avons décidé d'utiliser le même code que le cache du prototype de base de données, mais cela a échoué, nous avons donc dû revenir à VS.NET 2005.
On retrouve la classe Timer sous l'espace de noms System.Threading. Cette classe est très utile, mais peu de gens la connaissent, et encore moins de développeurs web la connaissent. Une fois qu'il a créé une instance de cette classe, la classe Timer appellera la fonction de rappel spécifiée à partir d'un thread du pool de threads à chaque heure spécifiée. Cela signifie que votre application ASP.NET peut s'exécuter même en l'absence de requête. C’est la solution à aborder plus tard. Vous pouvez exécuter le travail d'indexation et d'envoi de courrier électronique en arrière-plan au lieu de devoir l'exécuter à chaque demande.
Il existe deux problèmes avec la technologie d'exécution en arrière-plan. Le premier est que lorsque votre domaine d'application est désinstallé, l'instance de la classe Timer cesse de s'exécuter. Autrement dit, la méthode de rappel ne sera pas appelée. De plus, comme il y a de nombreux threads en cours d'exécution dans chaque processus du CLR, il vous sera difficile d'obtenir un thread pour que Timer l'exécute, ou il pourra l'exécuter, mais il sera retardé. La couche Asp.net doit utiliser cette technique le moins possible pour réduire le nombre de threads dans le processus, ou autoriser uniquement les requêtes à utiliser une petite partie des threads. Bien entendu, vous ne pouvez l’utiliser que si vous avez beaucoup de travail asynchrone.
Il n'y a pas assez d'espace pour publier le code ici. Vous pouvez télécharger l'exemple de programme depuis http://www.rob-howard.net/ . Veuillez télécharger l'exemple de programme Blackbelt TechEd 2004.
7. Mise en cache de sortie de page et services proxy
Asp.net est votre couche d'interface (ou devrait l'être), elle contient des pages, des contrôles utilisateur, des contrôles serveur (HttpHandlers et HttpModules) et le contenu qu'ils génèrent. Si vous disposez d'une page Asp.net qui génère des données HTML, XML, imgae ou autres et que vous utilisez du code pour générer le même contenu de sortie pour chaque requête, il est nécessaire d'envisager d'utiliser la mise en cache de sortie de page.
Vous pouvez le faire en copiant simplement la ligne de code suivante dans votre page :
<%@ PageOutputCache VaryByParams=”aucun” Durée=”60” %>
Vous pouvez utiliser efficacement la page générée lors de la première requête pour afficher le contenu mis en cache et régénérer le contenu de la page après 60 secondes. Cette technologie est en fait implémentée à l’aide d’une API Cache de bas niveau. Plusieurs paramètres peuvent être configurés pour la mise en cache de la sortie de page, tels que le paramètre VaryByParams mentionné ci-dessus. Ce paramètre indique quand déclencher les conditions de réédition. Vous pouvez également spécifier de mettre en cache la sortie en mode de requête Http Get ou Http Post. Par exemple, lorsque nous définissons ce paramètre sur VaryByParams="Report", la sortie demandée par default.aspx?Report=1 ou default.aspx?Report=2 sera mise en cache. La valeur d'un paramètre peut être constituée de plusieurs paramètres séparés par des points-virgules.
Beaucoup de gens ne réalisent pas que lors de l'utilisation de la mise en cache de sortie de page, ASP.NET génère également un ensemble d'en-têtes HTTP (en-tête HTTP) et l'enregistre dans le serveur de cache en aval. Ces informations peuvent être utilisées pour la sécurité Internet de Microsoft et pour accélérer le processus. vitesse de réponse du serveur. Lorsque l'en-tête du cache HTTP est réinitialisé, le contenu demandé sera mis en cache dans la ressource réseau. Lorsque le client demandera à nouveau le contenu, il n'obtiendra plus le contenu du serveur d'origine, mais obtiendra directement le contenu du cache.
Bien que l'utilisation de la mise en cache de sortie de page n'améliore pas les performances de votre application, elle réduit le nombre de fois où le contenu de la page mis en cache est chargé à partir du serveur. Bien entendu, cela se limite à la mise en cache des pages accessibles aux utilisateurs anonymes. Car une fois la page mise en cache, les opérations d’autorisation ne peuvent plus être effectuées.
8. Utilisez la mise en cache du noyau d'IIS6.0
Si votre application ne s'exécute pas dans IIS 6.0 (Windows Server 2003), vous avez perdu d'excellents moyens d'améliorer les performances des applications. Dans la septième méthode, j'ai expliqué comment utiliser la mise en cache de sortie de page pour améliorer les performances des applications. Dans IIS5.0, lorsqu'une requête arrive à IIS, IIS la transfère vers asp.net Lorsque le cache de sortie de page est appliqué, le HttpHandler dans ASP.NET recevra la requête et le HttpHandler transférera le contenu du cache. . Sortez-le et retournez-le.
Si vous utilisez IIS6.0, il possède une très bonne fonctionnalité appelée Kernel Caching et vous n'avez pas besoin de modifier le code dans le programme asp.net. Lorsque asp.net reçoit une requête mise en cache, le cache du noyau d'IIS en obtient une copie à partir du cache. Lorsqu'une requête provient du réseau, la couche noyau recevra la requête. Si la requête est mise en cache, elle renverra directement les données mises en cache, et vous avez terminé. Cela signifie que lorsque vous utilisez IIS Kernel Caching pour mettre en cache la sortie des pages, vous obtiendrez des améliorations de performances incroyables. Lors du développement d'asp.net pour VS.NET 2005, j'étais un gestionnaire de programme spécifiquement responsable des performances d'asp.net. Mes programmeurs ont utilisé cette méthode, j'ai examiné toutes les données du rapport quotidien et j'ai trouvé les résultats de l'utilisation de la mise en cache du modèle de noyau. le plus rapide. Une caractéristique commune d'entre eux est que les requêtes et les réponses du réseau sont volumineuses, mais IIS n'occupe que 5 % des ressources du processeur. C'est incroyable. Il existe de nombreuses raisons pour lesquelles vous utilisez IIS 6.0, mais l'encaissement du noyau est la meilleure.
9. Compresser les données avec Gzip
À moins que votre utilisation du processeur ne soit trop élevée, il est nécessaire d'utiliser des techniques pour améliorer les performances du serveur. L'utilisation de gzip pour compresser les données peut réduire la quantité de données que vous envoyez au serveur, améliorer la vitesse d'exécution de la page et également réduire le trafic réseau. La meilleure façon de compresser les données dépend des données que vous souhaitez envoyer et du fait que le navigateur du client les prend en charge (IIS envoie des données compressées par gzip au client, et le client doit prendre en charge gzip pour les analyser, IE6.0 et Firefox). De cette façon, votre serveur peut répondre à plus de requêtes par seconde. De même, vous réduisez également la quantité de données envoyées dans la réponse et vous pouvez envoyer plus de requêtes.
Bonne nouvelle, la compression gzip a été intégrée dans IIS6.0, elle est meilleure que gzip dans IIS5.0. Malheureusement, pour activer la compression gzip dans IIS 6.0, vous ne pouvez pas la définir dans la boîte de dialogue des propriétés d'IIS 6.0. L'équipe de développement IIS a développé la fonction de compression gzip, mais elle a oublié de permettre aux administrateurs de l'activer facilement dans la fenêtre d'administrateur. Pour activer la compression gzip, vous pouvez uniquement modifier sa configuration dans le fichier de configuration XML IIS6.0.
En plus de lire cet article, je dois lire l'article « IIS6 Compression » écrit par Brad Wilson ( http://www.dotnetdevs.com/articles/IIS6compression.aspx ) ; de compression aspx. Activez la compression ASPX dans IIS. Mais sachez que la compression dynamique et la mise en cache du noyau s'excluent mutuellement dans IIS6.
10. ViewState des contrôles du serveur
ViewState est une fonctionnalité d'asp.net utilisée pour enregistrer une valeur d'état utilisée pour générer une page dans un champ masqué. Lorsque la page est renvoyée sur le serveur, celui-ci analyse, vérifie et applique les données dans ViewState pour restaurer l'arborescence de contrôle de la page. ViewState est une fonctionnalité très utile qui peut conserver l'état du client sans utiliser de cookies ni de mémoire du serveur. La plupart des contrôles serveur utilisent ViewState pour conserver les valeurs d'état des éléments qui interagissent avec l'utilisateur sur la page. Par exemple, pour enregistrer le numéro de page de la page actuelle pour la pagination.
L'utilisation de ViewState entraînera des effets négatifs. Premièrement, cela augmente les temps de réponse et de requête du serveur. Deuxièmement, chaque publication ajoute du temps pour sérialiser et désérialiser les données. Enfin, cela consomme également plus de mémoire sur le serveur.
De nombreux contrôles serveur ont tendance à utiliser ViewState, comme le célèbre DataGrid, et parfois il n'est pas nécessaire de l'utiliser. ViewState est activé par défaut. Si vous ne souhaitez pas utiliser ViewState, vous pouvez le désactiver au niveau du contrôle ou de la page. Dans le contrôle, il vous suffit de définir la propriété EnableViewState sur False. Vous pouvez également la définir dans la page pour étendre sa portée à la page entière :
<%@ Page EnableViewState="false" %>
Si la page ne nécessite pas de publication ou si la page est simplement rendue avec des contrôles à chaque fois qu'elle est demandée. Vous devez désactiver ViewState au niveau de la page.
Résumer
Je fournis simplement quelques conseils qui, je pense, aideront à améliorer l'écriture d'applications ASP.NET hautes performances. Les conseils pour améliorer les performances d'ASP.NET mentionnés dans cet article ne sont qu'un point de départ. Pour plus d'informations, veuillez vous référer à « Amélioration d'ASP. NET" Performances ". Ce n'est que grâce à votre propre pratique que vous pourrez trouver les techniques qui seront les plus utiles pour votre projet. Cependant, ces conseils peuvent servir de guide dans votre parcours de développement. Dans le développement de logiciels, aucun de ces éléments n’est absolument utile car chaque projet est différent.
