Développement d'applications ASP.NET haute performance

Article
10/22/2014

Les instructions de cette rubrique répertorient les techniques que vous pouvez utiliser pour optimiser le débit des applications Web ASP.NET. Ces instructions sont réparties en différentes sections :

Traitement des pages et des contrôles serveur
Gestion d'état
Accès aux données
Applications Web
Méthodes de codage

Traitement des pages et des contrôles serveur

Les instructions suivantes proposent différents moyens d'utiliser les contrôles et les pages ASP.NET de façon efficace.

Éviter les allers-retours inutiles vers le serveur Dans certaines circonstances, l'utilisation des contrôles serveur ASP.NET et la gestion d'événements de publication sont inutiles. Par exemple, la validation des entrées d'utilisateur dans les pages Web ASP.NET peut souvent être effectuée sur le client, avant que ces données ne soient soumises au serveur. En général, si vous n'avez pas besoin de transmettre au serveur des informations à vérifier ou à écrire dans un magasin de données, vous pouvez améliorer la performance de la page et le travail de l'utilisateur en évitant tout code qui provoque un aller-retour vers le serveur. Vous pouvez aussi utiliser les rappels clients pour lire les données depuis le serveur au lieu d'exécuter un aller-retour complet. Pour plus d'informations, consultez Implémentation des rappels de clients sans publication dans des pages Web ASP.NET.

Si vous développez des contrôles serveur personnalisés, pensez à ce qu'ils puissent restituer le code côté client pour les navigateurs qui prennent en charge ECMAScript (JavaScript). En utilisant les contrôles serveur de cette façon, vous pouvez réduire de façon spectaculaire le nombre de fois où les informations sont envoyées au serveur Web. Pour plus d'informations, consultez Développement de contrôles serveur ASP.NET personnalisés.
Utiliser la propriété IsPostBack de l'objet Page pour éviter d'effectuer un traitement inutile lors d'un un aller-retour Si vous écrivez du code qui gère le traitement de publication des contrôles serveur, vous souhaiterez quelquefois que le code s'exécute uniquement lors du premier appel de la page plutôt que lors de chaque publication. Utilisez la propriété IsPostBack pour exécuter le code de façon conditionnelle, selon que la page est générée en réponse à un événement de contrôle serveur.
N'enregistrer l'état d'affichage du contrôle serveur que si nécessaire La gestion automatique de l'état d'affichage permet aux contrôles serveur de compléter leurs valeurs de propriétés lors d'un aller-retour sans devoir écrire la moindre ligne de code. Toutefois, cette fonctionnalité a une incidence sur les performances puisque l'état d'affichage du contrôle serveur fait l'objet d'un aller-retour vers le serveur, dans un champ de formulaire masqué. Il est utile de savoir quand l'état d'affichage améliore les performances de votre page et quand il l'entrave. Par exemple, si vous liez un contrôle serveur aux données lors de chaque aller-retour, l'état d'affichage enregistré n'est pas utile, parce que les valeurs du contrôle sont remplacées par les nouvelles valeurs pendant la liaison de données. Dans ce cas, la désactivation de l'état d'affichage économise le temps de traitement et réduit la taille de la page.

L'état d'affichage est activé pour tous les contrôles serveur par défaut. Pour le désactiver, définissez la propriété EnableViewState du contrôle avec la valeur false, comme dans l'exemple de contrôle serveur DataGrid suivant :
```
<asp:datagrid EnableViewState="false" datasource="..." 
   runat="server"/>
```
Vous pouvez aussi désactiver l'état d'affichage pour une page entière en utilisant la directive @ Page. Cela est utile lorsque vous ne publiez pas sur le serveur à partir d'une page :
```
<%@ Page EnableViewState="false" %>
```
Notes

L'attribut EnableViewState est également pris en charge dans la directive @ Control pour spécifier si l'état d'affichage est activé pour un contrôle utilisateur.

Pour analyser la taille de l'état d'affichage utilisée par les contrôles serveur de votre page, activez le traçage de la page en incluant l'attribut trace="true" dans la directive @ Page. Dans la sortie de traçage, examinez la colonne Viewstate du tableau Hiérarchie des contrôles. Pour plus d'informations sur le traçage et sur la façon de l'activer, consultez Traçage ASP.NET.
Laisser la mise en mémoire tampon activée, sauf si vous avez une raison spécifique de la désactiver La désactivation de la mise en mémoire tampon des pages Web ASP.NET possède un coût significatif en termes de performance. Pour plus d'informations, consultez la propriété Buffer.
Utilisez la méthode Transfer de l'objet Server ou la publication sur plusieurs pages pour procéder à une redirection entre des pages ASP.NET de la même application Pour plus d'informations, consultez Redirection des utilisateurs vers une autre page.

Gestion des états

Les instructions suivantes proposent des solutions pour rendre la gestion d'état efficace.

Désactiver l'état de session lorsqu'il n'est pas utilisé Certaines applications ou pages ne requièrent pas l'état de session par utilisateur ; désactivez l'état de session s'il n'est pas nécessaire. Pour désactiver l'état de session d'une page, affectez la valeur false à l'attribut EnableSessionState dans la directive @ Page, comme dans l'exemple suivant :
```
<%@ Page EnableSessionState="false" %>
```
Notes

Si une page requiert l'accès aux variables de session, mais ne les crée pas ou ne les modifie pas, définissez l'attribut EnableSessionState de la directive @ Page avec la valeur ReadOnly.

Vous pouvez aussi désactiver l'état de session pour les méthodes des services Web XML. Pour plus d'informations, consultez Services Web XML créés à l'aide de clients de service Web XML et d'ASP.NET.

Pour désactiver l'état de session pour une application, définissez l'attribut Mode avec la valeur Off dans la section SessionState du fichier Web.config de l'application, comme dans l'exemple suivant :
```
<sessionState mode="Off" />
```
Choisir le fournisseur d'états de session approprié à l'application ASP.NET offre plusieurs moyens de stocker 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 Server. (Vous pouvez aussi créer un fournisseur d'états de session personnalisé pour stocker les données de session dans un magasin de données de votre choix.) Chaque solution présente ses avantages, mais l'état de session in-process est de loin la solution la plus rapide. Si vous ne stockez qu'une petite quantité de données volatiles dans l'état de session, nous vous recommandons d'utiliser le fournisseur in-process. Les options d'état de session out-of-process sont utiles si vous faites évoluer votre application sur plusieurs processeurs ou plusieurs ordinateurs, ou si vous souhaitez conserver les données de session quand un serveur ou un processus est redémarré. Pour plus d'informations, consultez État de session ASP.NET.

Accès aux données

Les instructions suivantes proposent des solutions pour rendre efficace l'accès aux données de votre application.

Utiliser SQL Server et les procédures stockées pour l'accès aux données De toutes les méthodes d'accès aux données fournies par le .NET Framework, l'utilisation de SQL Server pour l'accès aux données constitue le choix recommandé pour créer des applications Web évolutives et à hautes performances. Lorsque vous utilisez le fournisseur SQL Server managé, vous pouvez obtenir un gain de performance supplémentaire en utilisant chaque fois que possible des procédures stockées compilées à la place des commandes SQL. Pour plus d'informations sur l'utilisation des procédures stockées SQL Server, consultez Utilisation des procédures stockées avec une commande.
Utiliser la classe SqlDataReader pour un curseur de données avant seulement et rapide La classe SqlDataReader fournit un flux de données avant seulement, récupéré d'une base de données SQL Server. Si vous pouvez utiliser un flux de données en lecture seule dans votre application ASP.NET, la classe SqlDataReader offre de meilleures performances que la classe DataSet. La classe SqlDataReader utilise le format natif de transfert de données réseau de SQL Server pour lire directement les données à partir d'une connexion de base de données. Par exemple, lors de la liaison au contrôle SqlDataSource, vous obtenez une meilleure performance en définissant la propriété DataSourceMode avec la valeur DataReader. (L'utilisation d'un lecteur de données entraîne la perte d'un certain nombre de fonctionnalités.) De même, la classe SqlDataReader implémente l'interface IEnumerable, qui permet aussi de lier les données aux contrôles serveur. Pour plus d'informations, consultez la classe SqlDataReader. Pour plus d'informations sur la façon dont ASP.NET accède aux données, consultez Accès aux données avec ASP.NET.
Mettre en cache les données et les sorties de page chaque fois que possible ASP.NET fournit des mécanismes pour mettre en cache les données ou les sorties de page lorsqu'elles ne doivent pas être calculées dynamiquement à chaque demande de page. De plus, la conception de pages et de demandes de données à mettre en cache, en particulier dans les zones de votre site où vous attendez un trafic intense, peut optimiser la performance de ces pages. Une utilisation appropriée du cache peut améliorer la performance de votre site bien plus que l'utilisation de toute autre fonctionnalité du .NET Framework.

Lorsque vous utilisez la mise en cache ASP.NET, notez les éléments suivants. Premièrement, ne mettez pas en cache un trop grand nombre d'éléments. La mise en cache de chaque élément consomme de la mémoire. Les éléments qui sont aisément recalculés ou rarement utilisés ne doivent pas être mis en cache. Deuxièmement, n'assignez pas aux éléments mis en cache un délai d'expiration bref. Les éléments qui expirent rapidement provoquent un roulement inutile dans le cache et occasionnent fréquemment un surcroît de travail pour le code de nettoyage et le Garbage Collector. Vous pouvez surveiller le roulement dans le cache consécutif à l'expiration d'éléments en utilisant le compteur de performance Taux de rendement total du cache associé à l'objet de performance Applications ASP.NET. Un taux de rendement élevé peut indiquer un problème, en particulier si des éléments sont supprimés avant leur expiration. (Cette situation est quelquefois connue sous le nom de sollicitation de la mémoire.)

Pour plus d'informations sur la façon de mettre en cache les sorties de page et les demandes de données, consultez Vue d'ensemble de la mise en cache ASP.NET.
**Utiliser convenablement la dépendance de cache SQL **ASP.NET prend en charge l'interrogation basée sur des tables et la notification de requête, selon la version de SQL Server que vous utilisez. L'interrogation basée sur des tables est prise en charge par toutes les versions de SQL Server. Dans l'interrogation basée sur des tables, si un des éléments d'une table est modifié, tous les écouteurs sont invalidés. Cela peut provoquer une agitation inutile dans l'application. L'interrogation basée sur des tables n'est pas recommandée pour les tables dont les éléments sont souvent modifiés. Par exemple, l'interrogation basée sur des tables est recommandée sur une table de catalogue rarement modifiée. Elle n'est pas recommandée pour une table de commandes, plus fréquemment mise à jour. La notification de requête est prise en charge par SQL Server 2005. Elle prend en charge des requêtes spécifiques, qui réduisent le nombre de notifications envoyées lorsqu'une table est modifiée. Même si elle offre de meilleures performances que l'interrogation basée sur des tables, elle n'est pas adaptée à des milliers de requêtes.

Pour plus d'informations sur la dépendance de cache SQL, consultez Procédure pas à pas : utilisation de la mise en cache de sortie ASP.NET avec SQL Server ou Mise en cache dans ASP.NET avec la classe SqlCacheDependency.
**Utiliser la pagination et le tri de la source de données plutôt que la pagination et le tri de l'interface utilisateur **La fonctionnalité de pagination de l'interface utilisateur pour les contrôles de données, tels que DetailsView et GridView peut être utilisée avec n'importe quel objet de source de données qui prend en charge l'interface ICollection. Pour chaque opération de pagination, le contrôle de données interroge la source de données pour la collection de données entière et sélectionne les lignes à afficher, en ignorant le reste des données. Si une source de données implémente DataSourceView et si la propriété CanPage retourne la valeur true, le contrôle de données utilisera la pagination de la source de données plutôt que la pagination de l'interface utilisateur. Dans ce cas, le contrôle de données interrogera uniquement la ligne concernée pour chaque opération de pagination. La pagination de la source de données est donc plus efficace que la pagination de l'interface utilisateur. Seul le contrôle de source de données ObjectDataSource prend en charge la pagination de la source de données. Pour activer la pagination de la source de données sur d'autres contrôles de source de données, vous devez hériter du contrôle de source de données et modifier son comportement.

**Équilibrer l'avantage de la validation d'un événement en termes de sécurité avec son coût de performances **Les contrôles qui dérivent des classes System.Web.UI.WebControls et System.Web.UI.HtmlControls peuvent confirmer qu'un événement provient de l'interface utilisateur qui a été restituée par le contrôle. Cela permet d'empêcher le contrôle de répondre à une notification d'événement usurpée. Par exemple, le contrôle DetailsView peut empêcher le traitement d'un appel Delete (qui, par nature, n'est pas pris en charge dans le contrôle) et la suppression de données. Cette validation a un coût de performances. Vous pouvez contrôler ce comportement à l'aide de l'élément de configuration EnableEventValidation et de la méthode RegisterForEventValidation. Le coût de la validation dépend du nombre de contrôles sur la page et est de l'ordre de quelques pour cent.

Remarque de sécurité
Il est fortement recommandé de ne pas désactiver la validation des événements. Avant de désactiver la validation des événements, vous devez être sûr qu'aucune publication ne peut être générée et avoir un effet inattendu sur votre application.

Éviter d'utiliser le chiffrement des états d'affichage à moins que cela soit nécessaire Le chiffrement des états d'affichage empêche les utilisateurs de pouvoir lire les valeurs dans le champ des états d'affichage masqué. Un contrôle GridView qui comporte un champ d'identificateur dans la propriété DataKeyNames constitue un scénario classique. Le champ d'identificateur est nécessaire pour coordonner les mises à jour des enregistrements. Vous pouvez chiffrer les états d'affichage lorsque vous ne souhaitez pas que les utilisateurs puissent voir l'identificateur. Toutefois, le chiffrement présente un coût de performances constant pour l'initialisation et un coût supplémentaire qui dépend de la taille des états d'affichage à chiffrer. Le chiffrement est configuré pour chaque chargement de page. L'effet sur les performances est donc le même pour chaque chargement de page.
Utiliser la mise en cache, le tri et le filtrage SqlDataSource Si la propriété DataSourceMode du contrôle SqlDataSource a la valeur DataSet, SqlDataSource est capable de mettre en cache le jeu de résultats d'une requête. Si les données sont mises en cache de cette manière, les opérations de filtrage et de tri du contrôle (configurées avec les propriétés FilterExpression et SortParameterName ) les utilisent. Dans de nombreux cas, votre application s'exécutera plus vite si vous mettez en cache le groupe de données entier et si vous utilisez les propriétés FilterExpression et SortParameterName pour trier et filtrer, plutôt que d'utiliser des requêtes SQL avec des clauses WHERE et SORT BY qui accèdent à la base de données pour chaque action de sélection.

Applications Web

Les instructions suivantes proposent des solutions pour que vos applications Web fonctionnent efficacement comme un tout.

Envisager la précompilation Une application Web est compilée par lots lors la première demande d'une ressource, telle qu'une page Web ASP.NET. Si aucune page de l'application n'a été compilée, la compilation par lots compile toutes les pages du répertoire en segments pour améliorer l'utilisation du disque et de la mémoire. Vous pouvez utiliser l'Outil de compilation ASP.NET (Aspnet_compiler.exe) pour précompiler une application Web. Dans le cadre d'une compilation sur place, l'outil de compilation appelle le runtime ASP.NET pour compiler le site de la même manière que lorsqu'un utilisateur demande une page du site Web. Vous pouvez précompiler une application Web afin que le balisage de l'interface utilisateur soit conservé ou précompiler les pages afin que le code source ne puisse pas être modifié. Pour plus d'informations, consultez How to: Precompile ASP.NET Web Sites Comment : précompiler des sites Web ASP.NET.
Exécuter des applications Web out-of-process sur les services IIS (Internet Information Services) 5.0 Par défaut, ASP.NET sur les services IIS 5.0 répond aux demandes à l'aide d'un processus de traitement out-of-process. Cette fonctionnalité a été réglée pour un débit rapide. Du fait des nombreux avantages et fonctionnalités de l'exécution de ASP.NET dans un processus de traitement out-of-process, cette solution est recommandée pour les sites de production.
Recycler régulièrement les processus Vous devez régulièrement recycler les processus, à la fois pour la stabilité et les performances. Sur les longues périodes de temps, les ressources comportant des fuites de mémoire et des bogues peuvent affecter le débit du serveur Web, et le recyclage des processus nettoie la mémoire de ces types de problèmes. Toutefois, vous devez trouver le juste équilibre entre un recyclage régulier et un recyclage trop fréquent, car les coûts liés à l'arrêt du processus de traitement, au rechargement des pages et à l'obtention réitérée des ressources et des données peuvent annuler les avantages du recyclage.

Les applications Web ASP.NET s'exécutant sous Windows Server 2003, qui utilise IIS 6.0, ne requièrent pas le réglage du paramètre de modèle de processus, car ASP.NET utilise les paramètres du modèle de processus IIS 6.0.
Ajuster le nombre de threads par processus de traitement pour votre application si nécessaire L'architecture des demandes d'ASP.NET tente de trouver un équilibre entre le nombre de threads qui exécutent des demandes et les ressources disponibles. L'architecture n'autorise pas l'exécution de plus de demandes simultanées qu'il n'y a de puissance UC disponible. Cette technique est appelée déclenchement périodique de thread. Il existe toutefois des conditions dans lesquelles l'algorithme de déclenchement périodique de thread ne fonctionne pas bien. Vous pouvez surveiller le déclenchement périodique de threads dans l'Analyseur de performances Windows à l'aide du compteur de performance Nombre d'instances de pipeline associé à l'objet de performance Applications ASP.NET.

Lorsqu'une page Web ASP.NET appelle une ressource externe, comme lors d'un accès à une base de données ou d'une demande de service Web XML, la demande de page s'interrompt généralement jusqu'à ce que la ressource externe réponde, permettant ainsi à l'UC de traiter d'autres threads. Si une demande attend d'être traitée et qu'un thread du pool est libre, le traitement de la demande en attente commence. Le résultat peut être un nombre élevé de requêtes s'exécutant de façon simultanée et de threads en attente dans le processus de traitement ASP.NET ou le pool d'applications, ce qui entraîne un ralentissement du débit du serveur Web et une dégradation des performances.

Pour améliorer ce point, vous pouvez définir manuellement la limite imposée au nombre de threads dans le processus en modifiant les attributs MaxWorkerThreads et MaxIOThreads dans la section processModel du fichier Machine.config.

Notes

Les threads de traitement sont destinés au traitement des demandes ASP.NET, tandis que les threads d'E/S sont utilisés pour fournir des données issues de fichiers, de bases de données ou de services Web XML.

Les valeurs assignées aux attributs du modèle de processus représentent le nombre maximal de chaque type de thread par UC dans le processus. Pour un ordinateur à deux processeurs, le nombre maximal est égal au double de la valeur définie. Pour un ordinateur de quatre processeurs, ce nombre est égal à quatre fois la valeur définie. Les valeurs par défaut conviennent pour les ordinateurs à 1 ou 2 processeurs, mais pour des ordinateurs dotés d'un plus grand nombre de processeurs, la présence de 100 ou 200 threads dans le processus peut s'avérer plus néfaste que bénéfique pour les performances. Un trop grand nombre de threads dans le processus a tendance à ralentir le serveur à cause des commutateurs de contexte supplémentaires ; il en résulte que le système d'exploitation consomme des cycles CPU pour la maintenance de ces threads au lieu de traiter les demandes. Pour déterminer le nombre approprié de threads, le mieux est de tester les performances de votre application.
Pour les applications qui reposent largement sur les ressources externes, penser à activer le jardinage Web sur les ordinateurs multiprocesseurs Le modèle de processus ASP.NET facilite l'activation de l'évolutivité sur les ordinateurs multiprocesseurs en distribuant le travail entre plusieurs processus, un par UC, chacun ayant une affinité de processeur définie avec une UC. Cette technique s'appelle le jardinage Web. Si votre application utilise un serveur de base de données lent ou appelle des objets COM qui ont des dépendances externes (pour ne citer que deux possibilités), il peut s'avérer bénéfique d'activer le jardinage Web pour votre application. Cependant, vous devriez tester le fonctionnement de votre application dans un jardin Web avant de vous décider à l'activer sur un site Web de production.
Désactiver le mode débogage Désactivez toujours le mode débogage avant de déployer une application de production ou de mener des évaluations de performance. Si le mode débogage est activé, la performance de votre application peut s'en ressentir. Pour plus d'informations sur la syntaxe de définition du mode débogage, consultez Modification des fichiers de configuration ASP.NET.
Régler les fichiers de configuration de votre serveur Web et des applications spécifiques pour les adapter à vos besoins Par défaut, la configuration ASP.NET est définie de façon à activer l'ensemble le plus large de fonctionnalités et à accepter les scénarios les plus courants. Quelques paramètres de configuration par défaut peuvent être modifiés pour améliorer la performance de vos applications, selon les fonctionnalités utilisées. La liste suivante inclut les paramètres de configuration à prendre en compte :
- Activer uniquement l'authentification pour les applications qui la nécessitent Par défaut, le mode d'authentification pour les applications ASP.NET est Windows, ou NTLM intégré. Dans la plupart des cas, il est préférable de désactiver l'authentification dans le fichier Machine.config et de l'activer dans les fichiers Web.config des seules applications qui la requièrent.
- Configurer votre application avec les paramètres appropriés de codage des demandes et des réponses Par défaut, le codage d'ASP.NET est UTF-8. Si votre application utilise uniquement des caractères ASCII, configurez votre application en conséquence pour obtenir une légère amélioration des performances.
- Penser à désactiver AutoEventWireup pour votre application La définition de l'attribut AutoEventWireup avec la valeur false dans le fichier Machine.config signifie que la page ne liera pas les événements de page à la méthode basée sur une correspondance de nom (par exemple, Page_Load). Si vous désactivez AutoEventWireup, vos pages bénéficieront d'une légère amélioration des performances en vous laissant le soin de connecter les événements au lieu de l'effectuer automatiquement.
  
  Si vous souhaitez gérer des événements de page, utilisez l'une des deux stratégies suivantes. La première stratégie consiste à substituer les méthodes dans la classe de base. Par exemple, vous pouvez substituer la méthode OnLoad de l'objet Page pour l'événement de chargement de la page au lieu d'utiliser une méthode Page_Load. (Pensez à appeler la méthode de base pour garantir que tous les événements sont déclenchés.) La deuxième stratégie consiste à créer une liaison avec les événements à l'aide du mot clé Handles en Visual Basic ou à déléguer le rattachement en C#.
- Supprimer les modules inutilisés du pipeline de traitement de demande Par défaut, toutes les fonctionnalités demeurent actives dans le nœud HttpModules du fichier Machine.config de votre serveur. En fonction des fonctionnalités utilisées par votre application, vous pouvez être en mesure de supprimer les modules inutilisés du pipeline de demande pour obtenir une légère amélioration des performances. Examinez chaque module avec ses fonctionnalités et personnalisez-le en fonction de vos besoins. Par exemple, si vous n'utilisez pas l'état de session et la mise en cache de sortie dans votre application, vous pouvez supprimer ces deux fonctionnalités de la liste HttpModules ; ainsi, les demandes n'auront pas à appeler ces modules sans effectuer d'autre traitement significatif.

Méthodes de codage

Les instructions suivantes proposent des solutions pour écrire un code efficace.

Ne pas compter pas sur les exceptions de votre code Comme les exceptions peuvent provoquer une dégradation significative des performances, évitez de les utiliser comme moyen de contrôler le flux normal du programme. S'il est possible de détecter dans le code une condition qui provoquerait une exception, faites-le plutôt qu'intercepter l'exception elle-même et gérer la condition. Les scénarios courants de détection dans le code incluent le contrôle de null, en assignant une valeur à un objet String qui sera analysé en une valeur numérique, ou le contrôle de valeurs spécifiques avant d'appliquer des opérations mathématiques. L'exemple suivant illustre du code qui pourrait provoquer une exception et du code qui recherche une condition. Les deux génèrent le même résultat.
```
// This is not recommended.
try {
   result = 100 / num;
}
catch (Exception e) {
  result = 0;
}

// This is preferred.
if (num != 0)
   result = 100 / num;
else
  result = 0;
```
```
' This is not recommended.
Try
   result = 100 / num
Catch (e As Exception)
  result = 0
End Try

' This is preferred.
If Not (num = 0)
   result = 100 / num
Else
  result = 0
End If
```
Réécrire les composants COM gourmands en appels dans le code managé Le .NET Framework offre un moyen simple d'interagir avec les composants COM traditionnels. L'avantage est que vous pouvez tirer parti des fonctionnalités du .NET tout en conservant vos investissements existants dans les composants COM. Dans certaines circonstances cependant, le coût, en termes de performance, de conservation de vos anciens composants justifie leur migration vers du code managé. Chaque situation est unique et la meilleure façon de décider si vous devez migrer un composant est d'exécuter les mesures de performance de votre site Web. Il est recommandé d'examiner la migration de tout composant COM souvent appelé vers du code managé.

Dans de nombreux cas, il n'est pas possible de migrer des composants hérités vers du code managé, en particulier lors de la migration initiale de vos applications Web. Dans de tels cas, le marshaling des données des environnements non managés vers des environnements managés constitue l'un des plus principaux facteurs de dégradation des performances. Par conséquent, lorsque vous interagissez, exécutez autant de tâches que possible d'un côté ou de l'autre, puis effectuez un seul appel plutôt qu'une série d'appels plus petits. Par exemple, toutes les chaînes du Common Language Runtime sont en Unicode ; vous devez donc convertir toutes les chaînes en Unicode dans votre composant avant de faire appel au code managé.

Libérez les objets COM ou les ressources natives dès qu'ils ont fini d'être traités. Cela permet aux autres demandes de les utiliser et de minimiser les problèmes de performances qui surviendraient si le garbage collector devait les libérer ultérieurement.
Éviter les composants COM à thread cloisonné (STA, Single-Threaded Apartment) Par défaut, ASP.NET ne permet pas aux composants COM STA de s'exécuter dans une page. Pour les exécuter, vous devez inclure l'attribut ASPCompat=true dans la directive @ Page du fichier .aspx. Ce faisant, vous remplacez le pool de threads utilisé pour l'exécution de la page par un pool de threads STA tout en mettant l'objet HttpContext et les autres objets intégrés à la disposition de l'objet COM. Le fait d'éviter les composants COM STA permet également d'optimiser les performances, car il évite le marshaling d'appel des threads MTA (Multithreaded Apartment) vers les threads STA.

Si vous devez utiliser un composant COM STA, évitez d'effectuer de trop nombreux appels pendant l'exécution et essayez d'envoyer autant d'informations que possible pendant chaque appel. De même, évitez de créer des composants COM STA pendant la construction de la page. Par exemple, dans le code suivant, SampleSTAComponent serait instancié au moment de la construction de la page, créée à partir d'un thread qui n'est pas le thread STA exécutant la page. Cela peut avoir un impact négatif sur les performances, car nécessitant le marshaling entre les threads MTA et STA pour construire la page.
```
<%@ Page Language="VB" ASPCompat="true" %>
<script runat=server>
Dim myComp as new SampleSTAComponent()
Public Sub Page_Load()
    myComp.Name = "Sample"
End Sub
</script>
<html>
<%
    Response.Write(Server.HtmlEncode(myComp.SayHello))
%>
</html>
```
Le mécanisme privilégié consiste à différer la création d'objet jusqu'à ce que le code s'exécute sous un thread STA, comme dans l'exemple suivant :
```
<%@ Page Language="VB" ASPCompat="true" %>
<script runat=server>
Dim myComp
Public Sub Page_Load()
    myComp = new SampleSTAComponent()
    myComp.Name = "Sample"
End Sub
</script>
<html>
<%
    Response.Write(Server.HtmlEncode(myComp.SayHello))
%>
</html>
```
La méthode recommandée est de construire des composants COM et des ressources externes uniquement si nécessaire ou dans la méthode Page_Load.

Vous ne devez jamais stocker de composants COM STA dans une ressource partagée (comme le cache ou l'état de session) où ils sont accessibles par des threads autres que celui qui les a construits. Même si un thread STA effectue un appel à un composant COM STA, seul le thread qui a construit ce composant peut en réalité répondre à l'appel, ce qui provoque le marshaling de l'appel au thread créateur. Ce marshaling peut provoquer de sérieux problèmes de dégradation des performances et d'évolutivité. Dans de tels cas, pensez à transformer le composant COM en composant COM MTA ou à réécrire le composant en code managé.

Voir aussi

Concepts

Optimisation des performances dans ASP.NET
Contrôle de la performance des applications ASP.NET
Compteurs de performance pour ASP.NET

Autres ressources

Mise en cache ASP.NET

Partager via