Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Mise à jour : novembre 2007
Cette rubrique traite des optimisations de performances lors de l'utilisation des appartenances d'ASP.NET, des rôles, des propriétés de profil, de l'état de session, de la personnalisation des WebParts et de la navigation de site.
Appartenance
Cette section donne des informations sur l'utilisation efficace des appartenances d'ASP.NET.
Regroupement efficace des listes d'appartenance
Lorsque vous appelez des méthodes de la classe Membership, appelez les méthodes surchargées qui acceptent des membres PageIndex et PageSize. Ces surcharges s'exécutent plus vite parce qu'ainsi, moins de données sont transférées du serveur Web. Citons comme exemple la méthode GetAllUsers de la classe Membership. L'appel de la méthode GetAllUsers sans paramètres retourne tous les utilisateurs d'appartenance. A contraire, l'appel de la surcharge GetAllUsers retourne une seule page d'utilisateurs, en réduisant la quantité de données traitée par la page.
Résultats de la mise en cache lors de l'obtention du nombre d'utilisateurs en ligne
Vous pouvez appeler la méthode GetNumberOfUsersOnline pour afficher le nombre d'utilisateurs considérés comme actifs sur le site Web. Cette méthode examine chaque ligne de la table d'appartenances chaque fois que la méthode est appelée, ce qui peut réduire considérablement les performances si le nombre d'utilisateurs dans la base de données est élevé. Appelez la méthode uniquement lorsque cela est nécessaire et mettez la valeur en cache pendant un certain temps si vous n'avez pas besoin d'un nombre exact.
Rôles
Par défaut, la méthode GetRolesForUser est appelée automatiquement chaque fois qu'une page se charge, et retourne les rôles dans lesquels figure un utilisateur. Les rôles sont stockés dans un dictionnaire dans l'objet RolePrincipal. Pendant que la page Web s'exécute, la vérification des rôles est effectuée à l'aide de ce dictionnaire. Pour empêcher l'accès au fournisseur pour chaque chargement de la page et donc de réduire le temps de traitement serveur, affectez la valeur true à l'attribut CacheRolesInCookie dans le fichier Web.config de l'application. Ainsi, la liste des rôles de l'utilisateur est stockée dans un cookie. Lors des chargements de page suivants, les informations sur les rôles peuvent être lues dans le cookie au lieu d'utiliser un appel au fournisseur.
La méthode GetRolesForUser, la propriété IsInRole et la méthode GetRoles peuvent être utilisées dans le code pour vérifier l'appartenance à un rôle. En comprenant comment ces méthodes interagissent, vous pouvez écrire, pour votre application, le code qui fonctionne le plus efficacement pour la tâche que vous devez exécuter.
La méthode GetRolesForUser accède toujours au fournisseur. Un appel à la méthode IsInRole produit toujours un appel à la méthode GetRolesForUser lors de la première demande à une page lorsque la mise en cache des cookies n'est pas activée. Si la mise en cache des cookies est activée, les appels à la méthode IsInRole utiliseront à la place les informations de rôle mises en cache dans le cookie. Le premier appel à la méthode GetRoles produit un appel à la méthode GetRolesForUser, que la mise en cache des cookies soit activée ou pas. Les appels suivants à la méthode GetRoles sur une page utiliseront les informations de rôle mises en cache dans le RolePrincipal.
.gif "Remarque") Remarque : |
|---|
Le stockage d'informations sensibles dans un cookie peut exposer ces informations aux utilisateurs. Pour une sécurité maximale, n'activez pas la mise en cache des cookies. |
Propriétés de profil
Si votre code accède à une propriété de profil, lorsque la page est chargée, le fournisseur de profils lit toutes les propriétés de profil de l'utilisateur actuel. Plus précisément, le fournisseur lit toutes les propriétés qui sont associées à ce fournisseur de profils. Si des valeurs de propriétés de profil sont modifiées, les nouvelles informations sont de nouveau écrites dans le magasin de données du fournisseur lorsque la page est déchargée. ASP.NET peut déterminer si les types intrinsèques tels que les entiers et les chaînes ont changé, mais ne peut pas déterminer si les types non intrinsèques ont changé.
L'algorithme pour déterminer si les propriétés de profil sont enregistrées est le suivant :
Si tous les types de propriétés de profil sont des types intrinsèques et qu'aucun n'a changé, le profil n'est pas écrit dans le magasin de données.
Si tous les types de propriétés de profil sont des types intrinsèques et que certains ont changé, toutes les valeurs de propriété de profil sont écrites dans le magasin de données.
Si une propriété n'est pas un type intrinsèque, ASP.NET ne peut pas déterminer si une valeur a changé. Si le programme accède à la propriété dans le code, la valeur de la propriété est écrite dans le magasin de données.
Remarque :Dans tous les cas, la décision s'applique à toutes les propriétés de profil d'un fournisseur spécifique.
Si vous utilisez des types de propriété non intrinsèques, l'écriture des données de profil à la fin de chaque demande de page est longue. Vous pouvez atténuer cette charge comme suit :
Utilisez uniquement des types intrinsèques dans les profils.
Attribuez la valeur Off à l'attribut automaticSaveEnabled dans l'élément de configuration <profile>, et écrivez plutôt un code personnalisé pour détecter les modifications et enregistrer les valeurs des propriétés lorsque cela est nécessaire.
Écrivez un code personnalisé pour gérer l'événement ProfileAutoSaving, et dans le code d'événement, déterminez si des modifications ont été apportées aux propriétés de profil. Si aucune propriété n'a changé, annulez l'enregistrement automatique et attribuez la valeur false à la propriété ContinueWithProfileAutoSave de l'événement.
État de session
Les performances doivent être prises en compte lors de l'utilisation de tout mode d'état de session out-of-process (pour plus d'informations, consultez Modes d'état de session). Cette section donne des informations sur l'optimisation des performances de l'état de session.
Réduction de la charge de lecture et d'écriture de l'état de session
Par défaut, les informations d'état de session sont chargées lors de chaque chargement de la page. L'attribut EnableSessionState de la directive @ Page vous donne le contrôle sur l'état de session de chargement avec les paramètres suivants :
True Les données d'état de session sont lues à chaque chargement de la page et enregistrées en cas de changement. ASP.NET peut déterminer si les types intrinsèques tels que les entiers et les chaînes ont changé. Si toutes les valeurs d'état de session sont des types intrinsèques et qu'aucune n'a changé, la session n'est pas enregistrée. Si le type de certaines valeurs n'est pas intrinsèque, et si le programme accède à une valeur de session non intrinsèque, alors toutes les informations d'état de session sont enregistrées. En effet, ASP.NET ne suit pas les changements des types non intrinsèques et fait le choix le plus sûr en enregistrant toutes les données.
False Les données d'état de session ne sont pas lues lorsque la page est chargée.
ReadOnly Les données d'état de session à chaque chargement de la page, mais ne sont jamais enregistrées, même si une modification est apportée aux valeurs d'état de session dans le code.
Prévention des contentions de verrouillage pour la session d'état
Évitez d'utiliser des éléments <IFRAME> sur les pages qui requièrent l'état de session. Si plusieurs demandes sont envoyées à ASP.NET avec le même identificateur d'état de session, et si elles concernent toutes les pages ASP.NET où EnableSessionState a la valeur true, alors les demandes parallèles entreront en conflit pour le verrouillage qui est associé à l'état de session out-of-process. Dans le cas d'éléments <IFRAME>, cela signifie que les pages ASP.NET affichées dans plusieurs éléments <IFRAME> d'une page peuvent potentiellement entrer en conflit pour les mêmes données de session. Le résultat est que chaque demande séparée sera sérialisée sur le serveur.
Personnalisation des WebParts
Lorsqu'une page s'exécute, les informations de personnalisation ASP.NET sont chargées. Pour déterminer si toutes les informations de personnalisation des WebParts ont changé ou non, ASP.NET appelle la méthode Equals pour comparer les valeurs anciennes et nouvelles des propriétés ayant l'attribut PersonalizableAttribute.
Si une valeur de propriété de personnalisation a changé, les données de personnalisation sont enregistrées. Pour les types intrinsèques tels que les entiers, la méthode Equals compare directement les valeurs de propriété anciennes et nouvelles. Toutefois, pour les types non intrinsèques, ASP.NET compare la valeur de la référence, mais pas nécessairement les données gérées par une instance de type.
Par exemple, pour une propriété de type ArrayList, la méthode Equals compare les valeurs anciennes et nouvelles de la référence ArrayList, mais pas le contenu de l'objet ArrayList. La méthode Equals retournerait true si la référence ArrayList n'avait pas changé, même si un nouvel élément avait été ajouté à la liste. Dans ce cas, les données ArrayList ne seraient pas enregistrées.
Cet algorithme pour les types non intrinsèques est efficace, mais se trompe en ce qui concerne l'enregistrement des données. Si vous souhaitez enregistrer les données d'un type non intrinsèque tel qu'un objet ArrayList, affectez la valeur true à la propriété IsDirty si le contrôle dérive de WebPart, ou appelez la méthode SetPersonalizationDirty qui prend un contrôle comme paramètre.
Navigation de site
Les plans de sites volumineux ralentissent les performances par rapport à des plans de sites plus petits. Par exemple, dans les scénarios de test, l'augmentation du nombre de noeuds de 100 à 1000 (soit une multiplication par 10) peut augmenter le temps de chargement des pages d'environ un tiers.
La suppression de la sécurité, qui filtre les noeuds en fonction des rôles, entraîne une plus grande perte de performances que l'augmentation du nombre de noeuds. Par exemple, un plan de site comprenant 1000 noeuds a 10 fois plus de charge de traitement qu'un plan de site comprenant 100 noeuds.
Voici quelques recommandations pour limiter cet effet :
Lorsque la suppression de la sécurité est activée, le nombre maximal recommandé de noeuds est 150.
Définissez l'attribut Roles dans chaque noeud du plan de site. Lorsque cet attribut de rôles existe, ASP.NET peut ignorer l'URL et l'autorisation de fichier pour l'URL qui est associée au SiteMapNode, à condition qu'un utilisateur appartienne à l'un des rôles qui sont répertoriés dans l'attribut. Toutefois, notez que si un utilisateur n'appartient à aucun des rôles spécifiés, ASP.NET reviendra au fichier plus lent et aux contrôles d'autorisation d'URL.
Créez une classe qui hérite de la classe SiteMapProvider et substitue la méthode IsAccessibleToUser pour vérifier uniquement l'attribut Roles dans chaque noeud du plan de site. Cela accélère le processus de filtrage, car il ignore l'autorisation d'URL et de fichier. Toutefois, cette approche requiert deux définitions de sécurité parallèles dans l'application Web. La première est l'information d'autorisation dans le fichier Web.config (et les listes de contrôle d'accès NTFS pour l'autorisation de fichier si l'authentification Windows est activée). La seconde est l'information de rôle dans le plan du site. Vous devez comparer la charge de la gestion de la sécurité que représente le fractionnement des informations sur la sécurité et l'amélioration des performances du traitement du plan du site.
Pour plus d'informations, consultez Suppression de la sécurité sitemap ASP.NET et Autorisation ASP.NET.