28 règles d'optimisation des performances ASP recommandées par Microsoft

La performance est une fonctionnalité. Vous devez concevoir des performances dès le départ, sinon vous devrez réécrire votre application plus tard. Cela dit, quelles sont les bonnes stratégies pour optimiser les performances des applications Active Server Pages (ASP) ?

Cet article décrit les techniques d'optimisation des applications ASP et de Visual Basic® Scripting Edition (VBScript). Cet article aborde un certain nombre de pièges. Les suggestions répertoriées dans cet article ont été testées sur http://www.microsoft.com et sur d'autres sites, et les résultats ont été très significatifs. Cet article suppose que vous possédez déjà une compréhension de base du développement ASP, notamment VBScript et/ou JScript, l'application ASP, la session ASP et d'autres objets inhérents à ASP (requête, réponse et serveur).

En règle générale, les performances ASP dépendent principalement de nombreux facteurs autres que le code ASP lui-même. Plutôt que de répertorier toutes les informations dans un seul article, nous répertorions les ressources liées aux performances à la fin de l'article. Ces liens couvrent des sujets ASP et non-ASP, notamment les objets de données ActiveX® (ADO), le modèle d'objet de composant (COM), les bases de données et la configuration d'Internet Information Server (IIS). Voici quelques-uns de nos liens préférés – assurez-vous de les consulter.

Astuce 1 : mettre en cache les données fréquemment utilisées sur le serveur Web

Une page ASP typique récupère les données d'un magasin de données principal, puis convertit les résultats en langage HTML (Hypertext Markup Language). Quelle que soit la vitesse de la base de données, la récupération des données de la mémoire est toujours beaucoup plus rapide que la récupération des données du magasin de données principal. La lecture de données à partir d'un disque dur local est également généralement plus rapide que la récupération de données à partir d'une base de données. Par conséquent, les performances peuvent souvent être améliorées en mettant en cache les données sur le serveur Web (stockées en mémoire ou sur disque).

La mise en cache est la manière traditionnelle d’échanger de l’espace contre du temps. Si vous mettez en cache le bon contenu, vous pouvez constater une amélioration significative des performances. Pour que la mise en cache soit efficace, les données fréquemment réutilisées doivent être sauvegardées, et le recalcul de ces données nécessite une surcharge (modérée) importante. Si le cache contient uniquement des données obsolètes, cela entraînera un gaspillage de mémoire.

Les données qui changent rarement sont de bonnes candidates pour la mise en cache, car vous n'avez pas à vous soucier de la synchronisation de ces données avec la base de données au fil du temps. Les listes de zones de liste déroulante, les tables de référence, les fragments DHTML, les chaînes XML (Extensible Markup Language), les éléments de menu et les variables de configuration du site (y compris les noms de sources de données (DSN), les adresses IP (Internet Protocol) et les chemins Web) sont tous de bons caches. contenu. Notez que vous pouvez mettre en cache une « représentation » des données sans mettre en cache les données elles-mêmes. Si la page ASP change rarement et que la mise en cache est coûteuse (par exemple, un catalogue de produits complet), vous devriez envisager de générer le code HTML à l'avance plutôt que de le réafficher en réponse à chaque requête.

Où les données doivent-elles être mises en cache et quelles sont les stratégies de mise en cache ? En règle générale, les données sont mises en cache dans la mémoire ou sur le disque du serveur Web. Les deux conseils suivants couvrent les deux méthodes.

Astuce 2 : mettez en cache les données fréquemment utilisées dans les objets Application ou Session ASP.

Les objets Application et Session ASP fournissent des conteneurs pratiques pour la mise en cache des données en mémoire. Vous pouvez attribuer des données aux objets Application et Session, et les données restent en mémoire entre les appels HTTP. Les données de session sont stockées séparément pour chaque utilisateur, tandis que les données d'application sont partagées entre tous les utilisateurs.

Quand les données doivent-elles être chargées dans l’application ou la session ? En règle générale, les données sont chargées au démarrage de l'application ou de la session. Pour charger des données lors du démarrage de l'application ou de la session, ajoutez le code approprié à Application_OnStart() ou Session_OnStart() respectivement. Ces fonctions doivent être dans Global.asa, sinon vous pouvez les ajouter. Ces données peuvent également être chargées la première fois que cela est nécessaire. Pour ce faire, ajoutez du code à la page ASP (ou écrivez une fonction de script réutilisable) pour vérifier si les données existent et, sinon, chargez les données. Il s'agit d'une technique de performance traditionnelle appelée « évaluation paresseuse » : elle consiste à ne pas calculer une valeur avant de savoir que vous en avez besoin. Par exemple :

<%
Fonction GetEmploymentStatusList
Faible d
d = Application (?EmploymentStatusList?)
Si d = ?? Alors
'Fonction FetchEmploymentStatusList (non illustrée)
' récupère les données de la base de données, renvoie un tableau
d = RécupérerEmploymentStatusList()
Application(?EmploymentStatusList?) = d
Fin si
GetEmploymentStatusList = d
Fonction de fin
%>
Des fonctions similaires peuvent être écrites pour chaque bloc de données requis.

Sous quel format les données doivent-elles être stockées ? N'importe quel type de variante peut être stocké car toutes les variables de script sont des types de variantes. Par exemple, vous pouvez stocker des chaînes, des entiers ou des tableaux. En général, vous stockerez le contenu d'un jeu d'enregistrements ADO dans l'un de ces types de variables. Pour obtenir des données d'un jeu d'enregistrements ADO, vous pouvez copier manuellement les données dans des variables VBScript, un champ à la fois. Il est plus rapide et plus facile d'utiliser l'une des fonctions de persistance du jeu d'enregistrements ADO GetRows(), GetString() ou Save() (ADO 2.5). Les détails dépassent le cadre de cet article, mais voici un exemple de fonction qui utilise GetRows() pour renvoyer un tableau de données de jeu d'enregistrements :

'Obtenir un jeu d'enregistrements, renvoyer sous forme de tableau
Fonction FetchEmploymentStatusList
Dimrs
Définir rs = CreateObject(?ADODB.Recordset?)
rs.Open ? sélectionnez StatusName, StatusID depuis EmployeeStatus ?, _
?dsn=employés;uid=sa;pwd=;?
FetchEmploymentStatusList = rs.GetRows() ? Renvoie les données sous forme de tableau
rs.Fermer
Setrs=Rien
End Function

améliore encore l'exemple ci-dessus en mettant en cache HTML sous forme de liste au lieu d'un tableau. Voici un exemple simple :

'Obtenir le jeu d'enregistrements, renvoyer sous forme de liste d'options HTML
Fonction FetchEmploymentStatusList
Dim rs, fldName, s
Définir rs = CreateObject(?ADODB.Recordset?)
rs.Open ? sélectionnez StatusName, StatusID depuis EmployeeStatus ?, _
?dsn=employés;uid=sa;pwd=;?
s = ?<select name=??EmploymentStatus??> & vbCrLf
Définir fldName = rs.Fields(?StatusName?) ' Liaison de champ ADO
Faire jusqu'à rs.EOF
' La ligne suivante viole Don't Do String Concats,
' mais ce n'est pas grave car nous construisons un cache
s = s & ? <option>? & fldName & ?</option> & vbCrLf
rs.MoveNext
Boucle
s = s & ?</select>? & vbCrLf
rs.Fermer
Set rs = Nothing 'Voir la version anticipée
FetchEmploymentStatusList = s ' Renvoie les données sous forme de chaîne
Fonction de fin
Dans des conditions appropriées, le jeu d'enregistrements ADO lui-même peut être mis en cache dans l'étendue Application ou Session. Il y a deux mises en garde :

ADO doit être marqué comme étant à thread libre et des jeux d'enregistrements déconnectés doivent être utilisés.
Si ces deux exigences ne sont pas garanties, ne mettez pas en cache le jeu d'enregistrements ADO. Dans les conseils suivants « Composants non agiles » et « Ne pas mettre en cache les connexions », nous discutons des dangers liés au stockage d’objets COM dans la portée Application ou Session.

Lorsque vous stockez des données dans l'étendue Application ou Session, les données y restent jusqu'à ce que vous les modifiiez par programme, que la session expire ou que l'application Web soit redémarrée. Que faire si les données doivent être mises à jour ? Pour forcer manuellement une mise à jour des données de l'application, vous pouvez accéder à une page ASP réservée aux administrateurs pour mettre à jour les données. Alternativement, vous pouvez actualiser automatiquement les données à intervalles réguliers via une fonction. L'exemple suivant stocke un horodatage avec des données mises en cache et actualise les données après une certaine période de temps.

<%
' La remise des erreurs n'est pas affichée...
Const UPDATE_INTERVAL = 300 ' Intervalle de rafraîchissement, en secondes

' Fonction pour renvoyer la liste des statuts d'emploi
Fonction GetEmploymentStatusList
Mettre à jour le statut de l'emploi
GetEmploymentStatusList = Application(?EmploymentStatusList?)
End Function

' Mettre à jour périodiquement les données mises en cache
Sous-mise à jour de l'état de l'emploi
Dim d, strLastUpdate
strLastUpdate = Application(?LastUpdate?)
Si (strLastUpdate = ??) Ou _
(UPDATE_INTERVAL < DateDiff(?s?, strLastUpdate, Now)) Then

' Remarque : deux appels ou plus peuvent arriver ici. Ce n'est pas grave et cela se fera simplement.
' entraîne quelques récupérations inutiles (il existe une solution de contournement pour cela)

' Fonction FetchEmploymentStatusList (non illustrée)
' récupère les données de la base de données, renvoie un tableau
d = FetchEmploymentStatusList()

' Mettre à jour l'objet Application. Utiliser Application.Lock().
' pour garantir la cohérence des données
Application.Lock
Application(?EmploymentStatusList?) = Événements
Application(?LastUpdate?) = CStr(Maintenant)
Application.Déverrouiller
Fin si
Fin du sous-marin
Voir la ListBox la plus rapide au monde avec des données d'application, qui contient également un exemple.

Sachez que la mise en cache de grands tableaux dans des objets Session ou Application n'est pas une bonne pratique. La syntaxe du langage de script nécessite que l'intégralité du tableau soit temporairement copiée avant d'accéder à un élément du tableau. Par exemple, si vous mettez en cache un tableau de 100 000 éléments de chaînes qui mappent les codes postaux américains aux stations météorologiques locales dans un objet Application, ASP doit d'abord copier les 100 000 stations météorologiques dans un tableau temporaire. Ce n'est qu'après qu'une chaîne peut être extraite. Dans ce cas, il serait préférable de créer un composant personnalisé avec une méthode personnalisée pour stocker la station météo – ou d'utiliser un composant dictionnaire.

Juste un autre avertissement : ne jetez pas le bébé avec l'eau du bain : les tableaux peuvent être rapidement recherchés et stockés en mémoire sous forme de paires de données clés adjacentes. L'indexation d'un dictionnaire est beaucoup plus lente que l'indexation d'un tableau. Vous devez choisir la structure de données qui offre les meilleures performances pour votre situation.

Astuce 3 : Mettre en cache les données et le code HTML sur le disque du serveur Web

Parfois, il peut y avoir trop de données à mettre en cache en mémoire. "Trop" est simplement une façon de dire que cela dépend de la quantité de mémoire que vous souhaitez consommer, ainsi que du nombre d'éléments que vous devez mettre en cache et de la fréquence à laquelle vous souhaitez les récupérer. Dans tous les cas, si les données sont trop volumineuses pour être mises en cache en mémoire, envisagez de mettre en cache les données sur le disque dur du serveur Web sous forme de fichier texte ou XML. Les données peuvent être mises en cache simultanément sur disque et en mémoire pour établir la stratégie de mise en cache la plus appropriée pour votre site.

Notez que lors de la mesure des performances d'une seule page ASP, la récupération des données à partir du disque n'est pas nécessairement plus rapide que la récupération des données à partir d'une base de données. Mais la mise en cache réduit la charge sur la base de données et le réseau. Sous une charge importante, cela peut grandement améliorer le débit global. Ceci est très efficace lors de la mise en cache des résultats de requêtes coûteuses (telles que des jointures multi-tables ou des procédures stockées composées) ou de grands ensembles de résultats. Comme toujours, testez les avantages et les inconvénients de plusieurs options.

ASP et COM fournissent des outils pour configurer des solutions de mise en cache sur disque. Les fonctions ADO recordset Save() et Open() enregistrent et chargent les jeux d'enregistrements à partir du disque. Vous pouvez utiliser ces méthodes pour réécrire l'exemple de code dans la technique de mise en cache des données d'application ci-dessus, en utilisant Save() du fichier au lieu d'écrire le code dans l'objet Application.

Il existe quelques autres composants qui fonctionnent avec les fichiers :

Scripting.FileSystemObject vous permet de créer, lire et écrire des fichiers.
L'analyseur Microsoft® XML (MSXML) fourni avec Internet Explorer prend en charge l'enregistrement et le chargement de documents XML.
L'objet LookupTable (utilisé sur MSN, par exemple) est le meilleur choix pour charger des listes simples à partir du disque.
Enfin, envisagez de mettre en cache une représentation des données sur le disque plutôt que les données elles-mêmes. Le HTML pré-converti peut être stocké sur le disque dans des fichiers .htm ou .asp, et des hyperliens peuvent pointer directement vers ces fichiers. Vous pouvez utiliser des outils commerciaux, tels que XBuilder ou la fonctionnalité de publication Internet de Microsoft® SQL Server® pour automatiser le processus de génération HTML. Vous pouvez également placer l'extrait de code HTML dans un fichier .asp. Vous pouvez également utiliser FileSystemObject pour lire des fichiers HTML à partir du disque ou utiliser XML pour les convertir rapidement.

Astuce 4 : évitez de mettre en cache les composants non agiles dans les objets Application ou Session

Bien que la mise en cache des données dans les objets Application ou Session soit une bonne pratique, la mise en cache des objets COM présente de sérieux pièges. En règle générale, les utilisateurs ont tendance à mettre en cache les objets COM fréquemment utilisés dans des objets Application ou Session. Malheureusement, de nombreux objets COM (y compris tous les objets écrits en Visual Basic 6.0 ou version antérieure) provoquent de sérieux goulots d'étranglement lorsqu'ils sont stockés dans des objets Application ou Session.

Plus précisément, lorsqu'un composant non agile est mis en cache dans l'objet Session ou Application, cela entraîne un goulot d'étranglement des performances. Un composant agile est un composant marqué avec ThreadingModel=Both, qui regroupe un marshaleur à thread libre (FTM) ou un composant marqué avec ThreadingModel=Neutral ; (Le modèle Neutre est nouveau pour Windows® 2000 et COM+.) Les composants suivants ne sont pas agiles :

Composants à thread libre (sauf s'ils regroupent FTM).
Composants de fil d'appartement.
Composant à filetage unique.
Les composants configurés (bibliothèques Microsoft Transaction Server (MTS)/COM+ et packages/applications serveur) ne sont pas agiles à moins qu’il ne s’agisse de threads neutres. Les composants cloisonnés et autres composants non agiles sont mieux adaptés à la portée de la page (c'est-à-dire qu'ils sont créés et détruits sur une seule page ASP).

Dans IIS 4.0, les composants marqués par ThreadingModel=Both sont considérés comme agiles. Dans IIS 5.0, cela ne suffit pas. Les composants doivent non seulement être marqués Both, mais doivent également être agrégés FTM. L'article sur l'agilité décrit comment agréger FTM avec des composants C++ écrits dans la bibliothèque de modèles actifs. Sachez que si un composant met en cache des pointeurs d’interface, ces pointeurs eux-mêmes doivent être agiles ou doivent être stockés dans la table d’interface commune (GIT) COM. Si vous ne pouvez pas recompiler un composant à deux threads pour agréger FTM, vous pouvez marquer le composant avec ThreadingModel=Neutral. Alternativement, si vous ne souhaitez pas qu'IIS effectue des contrôles d'agilité (vous pouvez donc autoriser le stockage des composants non agiles dans la portée Application ou Session), vous pouvez définir AspTrackThreadingModel sur True dans la métabase. Changer AspTrackThreadingModel n’est pas recommandé.

IIS 5.0 générera une erreur si vous souhaitez stocker un composant non agile créé avec Server.CreateObject dans un objet Application. Vous pouvez éviter cette erreur en utilisant <object runat=server scope=application ...> dans Global.asa, mais cela n'est pas recommandé car cela peut conduire au regroupement et à la sérialisation, décrits ci-dessous.

Que se passe-t-il si vous mettez en cache des composants non agiles ? Les composants non agiles mis en cache dans l'objet Session verrouillent la session sur le thread de travail ASP. ASP gère un pool de threads de travail pour gérer les demandes. Normalement, une nouvelle requête est toujours gérée par le premier thread de travail disponible. Si la session est verrouillée sur un thread, la requête doit attendre que son thread associé soit disponible. Voici une analogie qui pourrait vous aider : vous allez dans un supermarché, choisissez certains articles et payez à la caisse n°_3. Par la suite, chaque fois que vous payez un article dans ce supermarché, vous devez toujours payer à la caisse n°_3, même s'il y a moins ou pas de files d'attente aux autres caisses.

Le stockage de composants non agiles dans la portée de l'application a un impact encore pire sur les performances. ASP doit créer un thread spécial pour exécuter les composants non agiles stockés dans la portée de l'application. Cela a deux conséquences : tous les appels doivent être acheminés vers ce fil de discussion et tous les appels sont mis en file d'attente. « Pooling » signifie que les paramètres doivent être stockés dans une zone de mémoire partagée ; effectuer un changement de contexte coûteux vers un thread spécial ; exécuter la méthode du composant dans la zone partagée ; effectuer un autre changement de contexte coûteux, Return control ; au fil d'origine. « Sérialisation » signifie qu'une seule méthode est exécutée à la fois. Deux threads de travail ASP différents ne peuvent pas exécuter simultanément plusieurs méthodes sur un composant partagé. Cela élimine la concurrence, en particulier sur les ordinateurs multiprocesseurs. Pour aggraver les choses, tous les composants non liés aux applications Agile partagent un seul thread (le STA hôte), de sorte que l'impact de la sérialisation est encore plus important.

Que puis-je faire ? Voici quelques règles générales. Si vous écrivez des objets à l'aide de Visual Basic (6.0) ou d'une version antérieure, ne les mettez pas en cache dans les objets Application ou Session. Si vous ne connaissez pas le modèle de thread d'un objet, ne le mettez pas en cache. Ne mettez pas en cache les objets non agiles, mais créez-les et publiez-les sur chaque page. Les objets s'exécutent directement sur le thread de travail ASP, il n'y a donc pas de regroupement ni de sérialisation. Si les objets COM s'exécutent sur un serveur IIS, les performances sont acceptables s'ils ne prennent pas beaucoup de temps à initialiser et à supprimer. Notez que les objets monothread ne doivent pas être utilisés de cette manière. Attention, VB peut créer des objets monothread ! Si vous devez utiliser un objet monothread (tel qu'une feuille de calcul Microsoft Excel) comme celui-ci, ne vous attendez pas à un débit élevé.

Lorsque ADO est marqué comme étant à thread libre, les jeux d'enregistrements ADO peuvent être mis en cache en toute sécurité. Pour marquer ADO comme étant à thread libre, utilisez le fichier Makfre15.bat, qui se trouve généralement dans le répertoire \Program FilesCommonSystemADO.

Avertissement Si vous utilisez Microsoft Access comme base de données, vous ne devez pas marquer ADO comme étant à thread libre. Le jeu d'enregistrements ADO doit également être déconnecté. En général, si vous ne contrôlez pas la configuration ADO sur votre site (par exemple, si vous êtes un éditeur de logiciels indépendant [ISV] vendant des applications Web à des clients qui gèrent leurs propres configurations), il est préférable de ne pas mettre de jeux d'enregistrements en cache.

Les composants du dictionnaire sont également des objets agiles. LookupTable charge ses données à partir d'un fichier de données et peut être utilisé pour les données de zone de liste déroulante et les informations de configuration. L'objet PageCache dans Duwamish Books fournit la syntaxe du dictionnaire, tout comme le dictionnaire Caprock. Ces objets ou leurs objets dérivés peuvent constituer la base d'une stratégie de mise en cache efficace. Notez que les objets Scripting.Dictionary ne sont pas agiles et ne doivent pas être stockés dans les étendues Application ou Session.

Astuce 5 : Ne mettez pas en cache les connexions à la base de données dans l'objet Application ou Session

. La mise en cache des connexions ADO est généralement une mauvaise stratégie. Si un objet Connection est stocké dans l'objet Application et utilisé dans toutes les pages, alors toutes les pages seront en compétition pour cette connexion. Si l'objet Connection est stocké dans l'objet Session ASP, une connexion à la base de données sera créée pour chaque utilisateur. Cela annulerait les avantages du regroupement de connexions et exercerait une pression inutile sur le serveur Web et la base de données.

Au lieu de mettre en cache les connexions à la base de données, vous pouvez créer et supprimer des objets ADO dans chaque page ASP qui utilise ADO. Ceci est efficace car IIS dispose d’un pool de connexions de base de données intégré. Pour être plus précis, IIS active automatiquement le regroupement de connexions OLEDB et ODBC. Cela garantit que les connexions créées et supprimées sur chaque page seront valides.

Étant donné que le jeu d'enregistrements connecté stocke une référence à la connexion à la base de données, vous ne devez pas mettre en cache le jeu d'enregistrements connecté dans l'objet Application ou Session. Toutefois, vous pouvez mettre en cache en toute sécurité les jeux d'enregistrements déconnectés qui ne contiennent pas de référence à leur connexion de données. Pour déconnecter un jeu d'enregistrements, effectuez les deux étapes suivantes :

Set rs = Server.CreateObject(?ADODB.RecordSet?)
rs.CursorLocation = adUseClient 'étape 1

' Remplir le jeu d'enregistrements avec des données
rs.Open strQuery, strProv

' Déconnectez maintenant le jeu d'enregistrements du fournisseur de données et de la source de données
rs.ActiveConnection = Rien ' étape 2
Des informations plus détaillées sur le regroupement de connexions sont disponibles dans les documents de référence ADO et SQL Server.

Astuce 6 : Utiliser correctement les objets de session

Maintenant que nous avons discuté des avantages de la mise en cache dans les applications et les sessions, parlons d'éviter l'utilisation d'objets de session. Comme indiqué ci-dessous, Session présente plusieurs inconvénients lorsqu'elle est utilisée sur des sites très fréquentés. « Occupé » désigne généralement un site qui nécessite des centaines de pages par seconde ou des milliers d'utilisateurs simultanés. Cette astuce est encore plus importante pour les sites qui doivent évoluer horizontalement, c'est-à-dire ceux qui utilisent plusieurs serveurs pour gérer la charge ou atteindre la tolérance aux pannes. Pour les sites plus petits, tels que les sites intranet, si vous souhaitez bénéficier des avantages apportés par Session, la surcharge du système augmentera inévitablement.

En bref, ASP crée automatiquement une session pour chaque utilisateur qui accède au serveur Web. Chaque session nécessite environ 10 Ko de surcharge mémoire (l'essentiel est que les données soient stockées dans la session), ce qui ralentit toutes les requêtes. La session reste valide jusqu'à ce que le délai d'expiration configuré (généralement 20 minutes) soit écoulé.

Le plus gros problème de Session n’est pas la performance, mais l’évolutivité. La session ne peut pas s'étendre sur plusieurs serveurs Web. Une fois qu'une session est créée sur un serveur, ses données y restent. Cela signifie que si vous utilisez Session dans une batterie de serveurs Web, vous devez concevoir une stratégie qui envoie toujours chaque requête utilisateur au serveur sur lequel se trouve la session de l'utilisateur. C'est ce qu'on appelle « coller » l'utilisateur au serveur Web. Le terme « session collante » en est dérivé. Si le serveur Web tombe en panne, les utilisateurs « bloqués » perdront leur état de session car la session n'est pas bloquée sur le disque.

Les stratégies pour réaliser des sessions persistantes incluent des solutions matérielles et logicielles. Des solutions telles que l'équilibrage de charge réseau dans Windows 2000 Advanced Server et Local Director de Cisco peuvent mettre en œuvre des sessions persistantes au détriment d'un certain degré d'évolutivité. Ces solutions sont imparfaites. Il n'est pas recommandé de déployer votre propre solution logicielle pour le moment (nous utilisions auparavant des filtres ISAPI et des transformations d'URL, etc.).

Les objets d'application ne s'étendent pas non plus sur plusieurs serveurs ; si vous devez partager et mettre à jour des données d'application sur une batterie de serveurs Web, vous devez utiliser une base de données principale. Toutefois, les données d'application en lecture seule restent utiles dans une batterie de serveurs Web.

La plupart des sites critiques nécessitent au moins deux serveurs Web, ne serait-ce que pour augmenter la disponibilité (pour gérer le basculement et la maintenance du serveur). Par conséquent, lors de la conception d'applications critiques, vous devez implémenter des « sessions persistantes » ou simplement éviter d'utiliser des sessions et toute autre technologie de gestion d'état qui stocke l'état de l'utilisateur sur un seul serveur Web.

Si vous n'utilisez pas de sessions, assurez-vous de les fermer. Vous pouvez le faire pour une application via le Gestionnaire des services Internet (voir la documentation ISM). Si vous décidez d'utiliser des sessions, il existe des moyens d'atténuer leur impact sur les performances.

Vous pouvez déplacer le contenu qui ne nécessite pas de session (tel que les écrans d'aide, les zones visiteurs, etc.) vers une autre application ASP dont la session est fermée. Vous pouvez indiquer à ASP page par page que vous n'avez plus besoin de l'objet Session sur cette page, en utilisant la directive suivante en haut de la page ASP :

<% @EnableSessionState=False %>

Une bonne raison d'utiliser ceci La directive est que ces sessions ont un problème intéressant avec les jeux de cadres. ASP garantit qu'une seule requête est exécutée dans la session à tout moment. Cela garantit que si le navigateur demande plusieurs pages pour un utilisateur, une seule requête ASP touche la session à la fois, évitant ainsi les problèmes multithread qui se produisent lors de l'accès à l'objet Session. Malheureusement, toutes les pages d'un jeu de cadres seront affichées en série, l'une après l'autre, plutôt que simultanément. Les utilisateurs devront peut-être attendre longtemps pour voir toutes les images. Morale de l'histoire : si certaines pages du jeu de cadres ne reposent pas sur Session, assurez-vous de le signaler à ASP à l'aide de la directive @EnableSessionState=False.

Il existe de nombreuses façons de gérer l'état de session qui peuvent remplacer l'utilisation d'objets Session. Pour de petites quantités d'état (moins de 4 Ko), nous recommandons généralement d'utiliser des cookies, des variables QueryString et des variables implicites. Pour les volumes de données plus importants, tels que les paniers d'achat, une base de données back-end est le choix le plus approprié. De nombreux écrits ont été publiés sur les techniques de gestion d'état dans les batteries de serveurs Web. Pour plus d’informations, consultez Référence sur l’état de la session.

Astuce 7 : Encapsuler le code dans des objets COM

Si vous disposez de beaucoup de VBScript ou de JScript, vous pouvez souvent améliorer les performances en déplaçant votre code dans des objets COM compilés. Le code compilé s'exécute généralement plus rapidement que le code interprété. Les objets COM compilés peuvent accéder à d'autres objets COM via la « liaison anticipée », qui est une méthode d'appel d'objets COM plus efficace que la « liaison tardive » utilisée par les scripts.

L'encapsulation du code dans des objets COM présente plusieurs avantages (outre les performances) :

les objets COM aident à séparer la logique de présentation de la logique métier.
Les objets COM garantissent la réutilisation du code.
De nombreux développeurs trouvent que le code écrit en VB, C++ ou Visual J++ est plus facile à déboguer qu'en ASP.
Les objets COM présentent également des inconvénients, notamment le temps de développement initial et la nécessité de compétences en programmation différentes. Notez que l’encapsulation d’une petite quantité d’ASP peut entraîner une dégradation des performances sans améliorer les performances. Cette situation se produit généralement lorsqu'une petite quantité de code ASP est encapsulée dans un objet COM. Dans ce cas, la surcharge liée à la création et à l’appel de l’objet COM dépasse les avantages du code compilé. Des essais et des erreurs doivent être utilisés pour déterminer quelle combinaison de script ASP et de code objet COM produit les meilleures performances. Notez qu'il existe des améliorations significatives en matière de scripts et de performances ADO dans Windows 2000/IIS 5.0 par rapport à Microsoft Windows NT® 4.0/IIS 4.0. Par conséquent, avec l’introduction d’IIS 5.0, l’avantage en termes de performances du code compilé par rapport au code ASP a diminué.

Pour une discussion détaillée des avantages et des inconvénients de l’utilisation de COM dans ASP, consultez Directives relatives aux composants ASP et programmation d’applications distribuées avec Microsoft Visual Basic 6.0. Si vous déployez des composants COM, il est particulièrement important de les tester sous charge. En fait, toutes les applications ASP doivent systématiquement être testées en charge.

Astuce 8 : Obtenez des ressources plus tard et publiez-les plus tôt.

Voici un petit conseil pour votre référence. D’une manière générale, il est préférable d’obtenir les ressources plus tard et de les libérer plus tôt. Cela s’applique aux objets COM ainsi qu’aux descripteurs de fichiers et autres ressources.

Cette méthode d'optimisation est principalement utilisée pour les connexions et les jeux d'enregistrements ADO. Lorsque vous avez terminé avec un jeu d'enregistrements, par exemple après avoir affiché une table et ses données, vous devez le publier immédiatement plutôt que d'attendre la fin de la page. Il est recommandé de définir la variable VBScript sur Nothing. Ne laissez pas un jeu d'enregistrements sortir de la portée. Libérez également tous les objets Command ou Connection associés (n'oubliez pas d'appeler Close() avant de définir le jeu d'enregistrements ou la connexion sur = Nothing). Cela réduit le temps dont dispose la base de données pour préparer les ressources à votre place et libère la connexion de la base de données au pool de connexions le plus rapidement possible.

Astuce 9 : L'exécution hors processus troque la performance contre la fiabilité

ASP et MTS/COM+ disposent d'options de configuration qui vous permettent de trouver un compromis entre fiabilité et performances. Lors de la création et du déploiement d'applications, vous devez savoir comment équilibrer les performances avec les deux.

Les options ASP configurent les applications ASP pour qu'elles s'exécutent de l'une des trois manières suivantes. Dans IIS 5.0, le terme « niveau d'isolement » a été introduit pour décrire ces options. Les trois niveaux d'isolement sont le niveau bas, le niveau moyen et le niveau élevé :

isolement de bas niveau. Ceci est pris en charge dans toutes les versions d’IIS et est le plus rapide. Il exécute ASP dans Inetinfo.exe, qui est le processus principal d'IIS. Si l'application ASP plante, IIS le fera également. (Pour redémarrer IIS sous IIS 4.0, l'administrateur du site Web doit surveiller le site à l'aide d'un outil tel qu'InetMon et activer un fichier de commandes pour redémarrer le serveur en cas de panne du serveur. IIS 5.0 a introduit le redémarrage fiable, méthode permettant de redémarrer automatiquement un serveur défaillant. ).
Isolement intermédiaire. IIS 5.0 a introduit ce nouveau niveau, appelé niveau hors processus car ASP s'exécute en dehors du processus IIS. Dans l'isolation intermédiaire, toutes les applications ASP configurées pour s'exécuter en tant qu'isolation intermédiaire partagent un espace de processus. Cela réduit le nombre de processus requis pour exécuter plusieurs applications ASP hors processus sur un seul serveur. L'isolation moyenne est le niveau d'isolation par défaut dans IIS 5.0.
Isolement avancé. Ce niveau est pris en charge dans IIS 4.0 et IIS 5.0, et l'isolation avancée est également hors processus. Si ASP plante, le serveur Web ne plante pas. L'application ASP redémarrera automatiquement la prochaine fois qu'une requête ASP sera effectuée. En isolation avancée, chaque application ASP configurée pour s'exécuter en isolation avancée s'exécute dans son propre espace de processus. Cela protège les applications ASP des interférences les unes avec les autres. L'inconvénient est qu'il nécessite un processus distinct pour chaque application ASP. Lorsque de nombreuses applications doivent s'exécuter sur un seul serveur, la surcharge du système augmente considérablement.
Quelle option est la meilleure ? Dans IIS 4.0, l’épuisement du processus réduira considérablement les performances. Dans IIS 5.0, de nombreuses améliorations ont été apportées pour minimiser la surcharge provoquée par l'exécution d'applications ASP hors processus. En fait, dans la grande majorité des tests, les applications ASP hors processus dans IIS 5.0 s'exécutaient plus rapidement que les applications en cours dans IIS 4.0. Quoi qu’il en soit, sur les deux plates-formes, le processus en cours (faible niveau d’isolation) fonctionne le mieux. Cependant, si le débit d’accès est relativement faible ou si le débit maximum est faible, les avantages d’un faible niveau d’isolation sont moins évidents. Par conséquent, la définition d'un niveau d'isolement faible peut s'avérer nécessaire uniquement si vous avez besoin de centaines ou de milliers de pages par seconde par serveur Web. Comme toujours, testez plusieurs configurations pour déterminer le compromis que vous souhaitez faire.

Notez que lorsque vous exécutez des applications ASP hors processus (isolation moyenne ou élevée), elles s'exécutent dans MTS sous NT4 et dans COM+ sous Windows 2000. Autrement dit, dans NT4, ils s'exécutent dans Mtx.exe ; sous Windows 2000, ils s'exécutent dans DllHost.exe. Vous pouvez voir ces processus s'exécuter dans le Gestionnaire des tâches. Vous pouvez également voir comment IIS configure un package MTS ou une application COM+ pour une application ASP hors processus.

Options COM Les composants COM disposent également de trois options de configuration, bien qu'elles ne soient pas exactement similaires aux options ASP. Les composants COM peuvent être « non configurés », configurés en tant qu'application de bibliothèque ou configurés en tant qu'application serveur. « Non configuré » signifie que le composant n'est pas enregistré auprès de COM+. Les composants s'exécuteront dans l'espace de processus du programme appelant, c'est-à-dire qu'ils sont « en cours ». Les applications de bibliothèque sont également en cours, mais utilisent les services COM+, notamment la sécurité, les transactions et la prise en charge du contexte. Les applications serveur sont configurées pour s'exécuter dans leur propre espace de processus.

Vous pouvez constater que les composants non configurés présentent de légers avantages par rapport aux applications de bibliothèque. Les applications de bibliothèque présentent de plus grands avantages en termes de performances que les applications serveur. En effet, les applications de bibliothèque s'exécutent dans le même processus qu'ASP, tandis que les applications serveur s'exécutent dans leurs propres processus. Les appels inter-processus sont plus coûteux que les appels intra-processus. De plus, lors de la transmission de données telles que des jeux d'enregistrements entre processus, toutes les données doivent être copiées entre les deux processus.

piège! Lorsque vous utilisez une application serveur COM, si vous transmettez des objets entre ASP et COM, assurez-vous que les objets effectuent un « regroupement par valeur » ou MBV. Les objets exécutant MBV se copient d'un processus à un autre. C'est mieux qu'une approche où l'objet est toujours dans le processus du créateur et où un autre processus appelle le processus de création à plusieurs reprises pour utiliser l'objet. Un jeu d’enregistrements ADO déconnecté sera « regroupé par valeur », contrairement à un jeu d’enregistrements connecté. Scripting.Dictionary n'exécute pas MBV et n'est pas transmis entre les processus. Enfin, une note aux programmeurs VB : MBV ne s'obtient pas en passant le paramètre ByVal. MBV est réalisé par l'auteur du composant d'origine.

ce qu'il faut faire?
Si on nous demandait de suggérer une configuration raisonnable qui équilibre performances et fiabilité, ce serait la suivante :

Dans IIS 4.0, utilisez le faible niveau d'isolation ASP et utilisez le package de serveur MTS.
Sur IIS 5.0, utilisez le niveau d'isolation moyen d'ASP et utilisez une application de bibliothèque COM+.
Il s'agit de principes très généraux : les sociétés d'hébergement exécutent généralement ASP avec des niveaux d'isolation moyens ou élevés, tandis que les serveurs Web à usage unique peuvent fonctionner avec des niveaux d'isolation faibles. Pesez le pour et le contre et décidez vous-même quelle configuration correspond le mieux à vos besoins.

Astuce 10: Utilisez des options explicites

Les options explicites doivent être utilisées dans les fichiers .asp. Cette directive est placée en haut du fichier .asp et oblige le développeur à déclarer toutes les variables à utiliser. De nombreux programmeurs trouvent cette méthode utile dans les applications de débogage car elle évite la possibilité de mauvais noms de noms de variables et de création accidentelle de nouvelles variables (par exemple, myxmlString =) au lieu de myxlmstring = ....

Peut-être plus important encore, les variables déclarées sont plus rapides que les variables non déclarées. De cette façon, chaque fois que le script utilise une variable non déclarée au moment de l'exécution, il le fait référence par son nom. D'un autre côté, les variables sont déclarées dans l'ordre, soit au moment de la compilation, soit à l'heure d'exécution. À partir de maintenant, les variables déclarées sont référencées dans cet ordre. Étant donné que l'option explicite explicite la déclaration variable, il garantit que toutes les variables sont déclarées, donc l'accès est rapide.

Astuce 11: Utiliser les variables locales dans les sous-programmes et les fonctions

variables locales sont les variables déclarées dans les sous-programmes et les fonctions. Dans une fonction ou un sous-programme, l'accès aux variables locales est plus rapide que l'accès variable global. L'utilisation de variables locales rendra également le code plus clair, de sorte que les variables locales doivent être utilisées chaque fois que possible.

Astuce 12: Copiez des données fréquemment utilisées dans les variables de script

Lors de l'accès aux objets COM dans ASP, les données d'objets fréquemment utilisées doivent être copiées dans les variables de script. Faire cela réduit les appels de méthode com, qui sont relativement chers par rapport à l'accès aux variables de script. Cette technique réduit également les recherches coûteuses lors de l'accès à des objets de collecte et de dictionnaire.

En général, si vous prévoyez d'accéder aux données des objets plus d'une fois, vous devez mettre les données dans les variables de script. La cible principale de cette optimisation est les variables de demande (variables de forme et de requête). Par exemple, votre site peut transmettre une variable de requête nommée UserId. Disons que cet utilisateur est référencé 12 fois sur une page particulière. Au lieu d'appeler la demande (? UserId?) 12 fois, vous pouvez attribuer UserId à une variable en haut de la page ASP. Utilisez ensuite cette variable sur toute la page. Cela enregistre 11 appels de méthode com.

En fait, l'accès à des propriétés ou des méthodes COM n'est pas si coûteuse. Voici un exemple d'un code assez commun (syntaxiquement parlant):

foo.bar.blah.baz = foo.bar.blah.qaz (1)
Si foo.bar.blah.zaq = foo.bar.blah.abc alors '...
Lorsque ce code s'exécute, voici ce qui se passe:

la variable FOO est résolue en un objet global.
La barre variable est résolue en tant que membre de FOO. Il s'agit en fait d'un appel de méthode com.
La variable Blah est résolue en tant que membre de Foo.bar. Ceci est un autre appel de méthode com.
La variable QAZ est résolue en tant que membre de foo.bar.blah. C'est vrai, c'est toujours un appel de méthode com.
Appelez foo.bar.blah.quaz (1). Un autre appel de méthode com. J'ai compris?
Effectuez à nouveau les étapes 1 à 3 pour analyser Baz. Le système ne sait pas si l'appel QAZ modifie le modèle d'objet, donc les étapes 1 à 3 doivent être effectuées à nouveau pour résoudre Baz.
Résolve Baz en tant que membre de foo.bar.blah. Attribuez des attributs.
Effectuez à nouveau les étapes 1 à 3 pour analyser Zaq.
Effectuez à nouveau les étapes 1 à 3 pour analyser ABC.
Comme vous pouvez le voir, l'efficacité est assez mauvaise (et lente). Une façon rapide d'écrire ce code dans vbscript est:

définir myobj = foo.bar.blah 'faire la résolution de blah une fois
Myobj.baz = myobj.qaz (1)
Si myobj.zaq = myobj.abc alors '...
Si vous utilisez VBScript 5.0 ou supérieur, vous pouvez écrire ce code en utilisant la déclaration avec:

avec foo.bar.blah
.baz = .qaz (1)
Si .zaq = .abc alors '...
...
Terminez par

noter que cette technique s'applique également à la programmation VB.

Astuce 13: Évitez les tableaux de redimension

des tableaux de redim doit être évité si possible. En termes de performances, si l'ordinateur a une taille de mémoire physique limitée, il est préférable de définir la dimensionnalité initiale du tableau dans son pire cas - ou de définir les dimensions sur son scénario de meilleur cas, puis de la redimensionner au besoin. Cela ne signifie pas simplement l'allocation de quelques mégaoctets de mémoire lorsque vous savez que vous n'en aurez pas besoin.

Le code suivant vous montre une utilisation inappropriée de Dim et Redim.

<%
Dimmyarray ()
RedImmyarray (2)
MyArray (0) =? Bonjour?
MyArray (1) =? Au revoir?
MyArray (2) =? Adieu?
...
«Un autre code où vous finissez par avoir besoin de plus d'espace se produit, puis ...
Redim Preserve MyArray (5)
MyArray (3) =? Plus de trucs?
MyArray (4) =? Encore plus de choses?
MyArray (5) =? Pourtant plus de choses?
%>

Il vaut mieux diminuer correctement la taille initiale du tableau depuis le début (dans ce cas, 5) que de redim le tableau pour l'agrandir. Vous pouvez gaspiller de la mémoire (si vous n'utilisez pas tous les éléments), mais l'avantage est qu'il devient plus rapide.

Astuce 14: Utilisez la tampon de réponse

Vous pouvez tamponner une page entière de sortie en activant la «tampon de réponse». Cela minimise la quantité d'écriture au navigateur, améliorant les performances globales. Chaque opération d'écriture entraîne des frais généraux significatifs (à la fois en IIS et en termes de quantité de données envoyées sur le réseau), donc moins il y a des écritures, mieux c'est. En raison de son démarrage lent et de son utilisation de l'algorithme Nagling (utilisé pour atténuer la congestion du réseau), TCP / IP est beaucoup plus efficace lors de l'envoi de quelques gros morceaux de données que lorsqu'il doit envoyer de nombreux petits morceaux.

Il existe deux façons d'activer la tampon de réponse. Tout d'abord, vous pouvez utiliser Internet Services Manager pour activer la tampon de réponse pour l'ensemble de l'application. Nous recommandons cette approche, permettant la tampon de réponse par défaut pour les nouvelles applications ASP dans IIS 4.0 et IIS 5.0. Deuxièmement, vous pouvez activer la tampon de réponse en ajoutant la ligne de code suivante près du haut de chaque page ASP:

<% réponse.buffer = true%>
Cette ligne de code doit être exécutée avant que toutes les données de réponse ne soient écrites au navigateur (c'est-à-dire avant que tout HTML n'apparaisse dans le script ASP et avant que les cookies soient définis en utilisant la collection Response.cookies). En général, il est préférable d'activer la tampon de réponse pour l'ensemble de l'application. De cette façon, vous n'avez pas à écrire la ligne de code ci-dessus en haut de chaque page.

Réponse.Flush
Une plainte courante concernant le tampon de réponse est que les utilisateurs perçoivent les pages ASP comme étant lentes à répondre (même si le temps de réponse global est amélioré) car ils doivent attendre que la page entière soit générée avant de pouvoir voir quoi que ce soit. Pour les pages à long terme, vous pouvez définir la réponse.buffer = false pour désactiver la tampon de réponse. Cependant, une meilleure stratégie consiste à utiliser la méthode Response.flush. Cette méthode envoie tout HTML converti par ASP au navigateur. Par exemple, après avoir converti les 100 premières lignes d'une table de 1 000 rangées, ASP peut appeler Response.flush pour forcer les résultats de la conversion au navigateur, permettant à l'utilisateur de voir les 100 premières lignes avant que les lignes restantes ne soient prêtes. Cette technique combine parfaitement la tampon de réponse avec le navigateur affichant progressivement des données.

(Notez que dans l'exemple de table à 1 000 rangs ci-dessus, de nombreux navigateurs ne commenceront pas à afficher le tableau jusqu'à ce qu'ils voient la balise de clôture </ Table>. Vérifiez si votre navigateur cible le prend en charge. Pour éviter cela, divisez la table en plusieurs tables avec Moins de lignes et de réponse à l'appel. La largeur du contenu de chaque cellule.)

Une autre plainte courante concernant la tampon de réponse est qu'elle prend beaucoup de mémoire de serveur lorsque de très grandes pages sont produites. Quelle que soit la méthode de génération de grandes pages, ce problème peut également être résolu par l'utilisation intelligente de la réponse.flush.

Astuce 15: scripts intégrés par lots et réponse. Écriture Instruction

VBScript Syntaxe <% = expression%> Écrivez la valeur de "Expression" dans le flux de sortie ASP. Si la tampon de réponse n'est pas activée, chaque instruction exécutée écrira des données au navigateur dans de nombreux petits paquets sur le réseau. C'est très lent. De plus, l'exécution entrecoupée d'une petite quantité de scripts et de HTML entraînera une commutation entre le moteur de script et HTML, réduisant ainsi les performances. Par conséquent, utilisez l'astuce suivante: utilisez des appels de réponse. Par exemple, dans l'exemple suivant, il y a une écriture dans le flux de réponse par champ par ligne, et il existe de nombreux commutateurs entre VBScript et HTML par ligne:

<Bile>
<% Pour chaque FLD dans Rs. champs%>
<h> <% = fld.name%> </th>
<%
Suivant
Bien que pas Rs.Eof
%>
<tr>
<% Pour chaque FLD dans Rs. champs%>
<td> <% = fld.value%> </td>
<% Suivant
</tr>
<% Rs.Movenext
Allez %>
</table>
Le code ci-dessous est plus efficace, avec une écriture dans le flux de réponse par ligne. Tout le code est contenu dans un bloc VBScript:

<ball
<%
Pour chaque FLD en Rs.fields
Réponse.write (? <h>? & Fld.name &? </ Th>? & Vbcrlf)
Suivant
Bien que pas Rs.Eof
Réponse.write (? <tr>?)
Pour chaque FLD en Rs. champs%>
Réponse.write (? <Td>? & Fld.value &? </td>? & Vbcrlf)
Suivant
Réponse.write? </tr>?
Wende
%>
</table>
Cette astuce fonctionne particulièrement bien lorsque la tampon de réponse est désactivée. C'est une bonne idée d'activer la tampon de réponse et de voir si la réponse par lots. L'écriture aide à améliorer les performances.

(Dans cet exemple particulier, la boucle imbriquée qui construit le corps de la table (bien que ce ne soit pas Rs.Eof ...) peut être remplacé par un appel Gettring soigneusement construit.)

Astuce 16: Si la page prend beaucoup de temps, faire si les utilisateurs sont impatients avant d'utiliser la réponse.SislientConnedCected

, ils peuvent abandonner la page ASP avant de commencer à exécuter leur demande. S'ils cliquent sur actualiser ou se déplacer vers une autre page du serveur, il y a une nouvelle demande en attente à la fin de la file d'attente de la demande ASP et une demande déconnectée au milieu de la file d'attente. Cela se produit souvent lorsque la charge sur le serveur est élevée (et donc la file d'attente de demande est longue et que les temps de réponse sont en conséquence longs), ce qui ne fait qu'aggraver la situation. Il est inutile d'exécuter des pages ASP (en particulier les pages ASP lents et grandes) si l'utilisateur n'est plus connecté. Vous pouvez vérifier cela en utilisant la propriété Response.SislientConnected. S'il revient faux, la réponse doit être appelée et le reste de la page doit être rejeté. En fait, IIS 5.0 a ce comportement programmé - chaque fois que ASP est sur le point d'exécuter une nouvelle demande, il vérifie la durée de la demande dans la file d'attente. S'il y attend depuis plus de 3 secondes, ASP vérifiera si le client est toujours connecté et, sinon, terminez la demande immédiatement. Vous pouvez ajuster le délai d'expiration de 3 secondes à une autre valeur en utilisant le paramètre AspqueueConnectionTestTime dans la métabase.

Vous pouvez également vérifier la réponse.SisclientConnedcected de temps à autre si la page prend beaucoup de temps. Lorsque la tampon de réponse est activée, il est de temps en temps une bonne idée d'effectuer une réponse.

Notez que sur IIS 4.0, Response.islientConnected ne fonctionnera pas correctement à moins que la réponse. Si la mise en mémoire tampon est activée, vous devez également effectuer Response.flush. Sur IIS 5.0, il n'est pas nécessaire de le faire - Response.SislientConnected fonctionne bien. Dans tous les cas, la réponse.SislientConnected aura des frais généraux, donc seulement si une opération prend au moins (disons) 500 millisecondes (longtemps si vous voulez maintenir un débit de dizaines de pages par seconde) utilisez-le. L'expérience montre que vous ne devez pas l'appeler à chaque fois qu'une boucle serrée est exécutée à plusieurs reprises, par exemple lors de l'affichage de nombreuses lignes d'une table - l'appeler toutes les vingt ou cinquante lignes peuvent être appropriées.

Astuce 17: Utilisez la balise <Object> pour les objets instanciés

si vous souhaitez référencer un objet qui n'est pas utilisé dans tous les chemins de code (en particulier les objets de serveur ou d'application), utilisez le <objet runat = server id = objName> TAG Déclaration dans global.asa eux au lieu d'utiliser la méthode Server.CreateObject. Server.CreateObject crée immédiatement des objets. Si vous n'utilisez pas l'objet à l'avenir, vous avez gaspillé les ressources. La balise <object id = objname> déclare Objname, mais Objname n'est pas créé tant que sa méthode ou sa propriété n'est pas utilisée pour la première fois.

Ceci est un autre exemple d'évaluation paresseuse.

Astuce 18: Utilisez les déclarations de typelib pour ADO et autres composants

Lorsque vous utilisez ADO, les développeurs ajoutent souvent ADOVBS.txt pour accéder à diverses constantes ADO. Ce fichier doit être inclus dans chaque page où les constantes doivent être utilisées. Ce fichier constant est assez grand, ajoutant beaucoup de frais généraux au temps de compilation et à la taille du script de chaque page ASP.

IIS 5.0 a introduit la possibilité de se lier aux bibliothèques de type de composants. Cela vous permet de référencer la bibliothèque de types une fois et de l'utiliser sur chaque page ASP. Il n'y a pas de surcharge de compilation de fichiers constants pour chaque page, et les développeurs de composants n'ont pas à créer des fichiers VBScript # _include à utiliser sur ASP.

Pour accéder à ADO typelib, placez l'énoncé suivant dans Global.asa.

<! - Metadata Name =? Microsoft ActiveX Data Objectts Library?
Type =? Typelib?
ou

<! - Type de métadonnées =? typelib?
File =? C: Program Files Common Files System ADO

MSADO15.DLL

? Les services fournissent un soutien. Utilisez ces fonctionnalités chaque fois que possible. Toutes ces technologies effectuent une validation côté client et une mise en cache de données, éliminant le besoin d'un aller-retour au serveur Web. Si vous exécutez un navigateur intelligent, le navigateur peut faire une certaine validation pour vous (par exemple, vérifier qu'une somme de contrôle de carte de crédit est valide avant de réaliser un message). Utilisez cette fonctionnalité chaque fois que possible. En réduisant lestiné destinés à client-serveur, vous réduisez la charge sur le serveur Web et réduisez le trafic réseau (bien que la première page envoyée au navigateur puisse être plus grande) et toutes les ressources projetées accessibles par le serveur. De plus, l'utilisateur n'a pas à lire une nouvelle page comme d'habitude, donc l'utilisateur se sent mieux. Faire cela ne signifie pas que vous pouvez ignorer la validation côté serveur - vous devez également faire la validation côté serveur également. Cela empêche le client de générer des données incorrectes pour une raison quelconque (comme un pirate, ou le navigateur n'exécute pas de routines de validation côté client).

Beaucoup de travail a été consacré au développement de HTML "indépendant" "indépendant du navigateur. En raison de cette préoccupation, les développeurs hésitent à utiliser des fonctionnalités de navigateur populaires qui pourraient améliorer les performances. Pour certains sites vraiment performants, les problèmes de «accès» du navigateur doivent être préoccupés, et une bonne stratégie consiste à optimiser la page pour l'adapter aux navigateurs populaires. Les capacités du navigateur peuvent être facilement détectées dans ASP à l'aide du composant Capacités du navigateur. Des outils tels que Microsoft FrontPage aident à concevoir un code approprié pour le navigateur et la version spécifique de HTML. Voyez quand est meilleur pire? Peser les compromis technologiques pour une discussion plus approfondie.

Astuce 20: Évitez d'utiliser la concaténation de la chaîne dans une boucle

Beaucoup de gens créent une chaîne dans une boucle, comme ceci:

S =? <Bile>?
Pour chaque FLD en Rs.fields
S = S &? <Th>?
Suivant

sans Rs.Eof
S = S & VBCRLF &?
Pour chaque FLD en Rs.fields
S = S &? <Td>?
Suivant
S = S &? </tr>?
rs.MoveNext
Wend

s = s & vbcrlf &? </ Table>?
Réponse.WRITE S
Certains problèmes surviennent avec cette approche. Le premier problème est que les cordes concaténées à plusieurs reprises prennent du temps à la puissance de deux. Un exemple plus simple illustrera ce problème plus clairement.

S = ??
Pour i = asc (? A?) À asc (? Z?)
s = s & ch (i)
Suivant
Dans la première itération, vous obtenez une chaîne à un caractères? A ?. Dans la deuxième itération, VBScript doit réaffecter la chaîne et copier deux caractères (? Ab?) En S. À la troisième itération, il doit également réaffecter S à nouveau et copier trois caractères en art. Sur n (26e) itérations, il doit réaffecter et copier n les caractères en art. Le total est 1 + 2 + 3 + ... + n, c'est-à-dire n * (n + 1) / 2 copies.

Dans l'exemple de record ci-dessus, s'il y a 100 enregistrements et 5 champs, la boucle intérieure sera exécutée 100 * 5 = 500 fois, et le temps passé pour toutes les copies et réallocation est proportionnel à 500 * 500 = 250 000. Il s'agit trop d'opérations de copie pour un ensemble d'enregistrements de taille moyenne.

Dans ce cas, le code pourrait être amélioré à l'aide de réponse.write () ou de script en ligne (<% = fld.value%>) au lieu de la concaténation des chaînes. Si le tampon de réponse est activé (il devrait), cela sera plus rapide car Response.Write ajout des données à la fin du tampon de réponse. Il n'y a pas de réallocation impliquée, il est donc très efficace.

Dans le cas spécifique de la conversion d'un enregistrement ADO en une table HTML, vous devriez envisager d'utiliser Getrows ou GetString.

Si vous concaténez les chaînes dans JScript, il est particulièrement recommandé d'utiliser l'opérateur + =, c'est-à-dire S + =? Une chaîne?

Astuce 21: Activer la mise en cache du navigateur et de proxy

par défaut, ASP désactive la mise en cache dans les navigateurs et les procurations. Cela a du sens parce que les pages ASP sont, par nature, dynamiques, avec des informations sous-jacentes qui changent au fil du temps. Si la page ne nécessite pas de rafraîchissement sur chaque vue, vous devez activer le navigateur et la mise en cache proxy. Cela permet aux navigateurs et proxys d'utiliser une copie "mise en cache" de la page pendant un certain temps, dont vous pouvez contrôler la durée. La mise en cache peut considérablement réduire la charge sur le serveur et raccourcir le temps d'attente de l'utilisateur.

Quelle page dynamique peut être utilisée comme page à mettre en cache? Voici quelques exemples:

page de prévision météo, sur cette page, les prévisions météorologiques sont mises à jour toutes les 5 minutes.
La page d'accueil énumère les articles ou les versions, mises à jour deux fois par jour.
Une liste de performances de fonds communs de placement où les statistiques de base sont mises à jour toutes les quelques heures.
Notez que lorsque la mise en cache de navigateur ou de proxy est utilisée, le nombre de visites connectées sur le serveur Web est réduite. Si vous souhaitez mesurer avec précision toutes les pages vues ou publications, vous ne souhaitez pas utiliser la mise en cache du navigateur et de procuration.

La mise en cache du navigateur est contrôlée par l'en-tête HTTP "Expiration", qui est envoyée au navigateur par le serveur Web. ASP fournit deux mécanismes simples pour envoyer cet en-tête. Pour définir le nombre de minutes après quoi une page expirera, définissez la propriété Response.expires. L'exemple suivant indique au navigateur que le contenu expire en 10 minutes:

<% de réponse.expires = 10%>

Réglage de la réponse.Expire à un nombre négatif ou 0 désactive la mise en cache. Assurez-vous d'utiliser un grand nombre négatif, tel que -1000 (un peu plus d'une journée) pour éviter un décalage entre le serveur et les horloges de navigateur. La deuxième propriété, réponse.ExpiresBsolute, vous permettra de définir l'heure spécifique où le contenu expirera:

<% Response.expiresAbsolute = #may 31 2001 13: 30: 15 #%>
Au lieu d'utiliser l'objet de réponse pour définir le temps d'expiration, vous pouvez écrire la balise <Meta> dans le HTML, généralement dans la section <A-Head> du fichier HTML. Certains navigateurs respecteront cette directive, contrairement aux procurations.

<Meta Http-Equiv =? Expire?
Enfin, vous pouvez utiliser la propriété Response.CacheControl pour indiquer si son contenu peut être mis en cache par un proxy HTTP. La définition de cette propriété sur "public" permet au proxy de mettre en cache ce contenu.

<% Response.CacheControl =? Public?
Par défaut, cette propriété est définie sur "Private". Notez que la mise en cache proxy ne doit pas être activée pour les pages qui affichent des données spécifiques à un utilisateur, car le proxy peut servir les pages utilisateur appartenant à d'autres utilisateurs.

Astuce 22: Utilisez le serveur

. Cette fonction est couramment utilisée pour rediriger l'utilisateur vers une page de connexion ou d'erreur. Étant donné que la redirection force une demande de nouvelle page, le résultat est que le navigateur doit effectuer deux aller-retour vers le serveur Web et que le serveur Web doit traiter une autre demande. IIS 5.0 introduit un nouveau serveur de fonctions.transfer, qui transfère l'exécution vers une autre page ASP sur le même serveur. Cela évite lestiné de contourner le navigateur de navigateur redondant, d'améliorer les performances globales du système et le temps de réponse de l'utilisateur. Vérifiez la "nouvelle direction" dans "Redirection", il devrait être server.transfer et server.exécute.

Voir également en tirant parti de l'ASP dans IIS 5.0 pour une liste complète de nouvelles fonctionnalités dans IIS 5.0 et ASP 3.0.

Astuce 23: Utilisez une barre oblique inverse dans les URL du répertoire

Une astuce connexe consiste à vous assurer d'utiliser une barre arrière (/) dans les URL qui pointent vers les répertoires. Si vous omettez la barre oblique de fuite, le navigateur fera une demande au serveur juste pour dire au serveur qu'il demande un répertoire. Le navigateur fait une deuxième demande, ajoutant une barre oblique à l'URL, et ce n'est qu'alors que le serveur peut répondre avec le document par défaut ou la liste du répertoire par défaut du répertoire (s'il n'y a pas de document par défaut et que la navigation de répertoire n'est activé). L'ajout de la barre oblique élimine le premier retour inutile. Pour faciliter la lecture des utilisateurs, la barre oblique de fuite dans le nom d'affichage peut être omise.

Par exemple, écrivez:

<a href =? Http: //msdn.microsoft.com/workshop/? Title =? Web msdn
Atelier?> Http://msdn.microsoft.com/Workshop </a>
Cela s'applique également aux URL pointant vers la page d'accueil sur un site Web: Utilisez ce qui suit: <a href =? Http: //msdn.microsoft.com/?> Au lieu de <a href =? Http: //msdn.microsoft .

Astuce 24: Évitez d'utiliser les variables du serveur

. La situation est similaire à la recherche d'un fichier dans un dossier dans un grenier moisi. Lorsque vous souhaitez trouver ce document, vous devez aller au grenier, trouver le dossier, puis trouver le document. La même chose se produit lorsque vous demandez une variable de serveur - la première fois que vous demandez une variable de serveur, les performances en souffrent. Les demandes ultérieures à d'autres variables de serveur n'auront pas d'impact sur les performances.

Ne jamais accéder à un objet de demande non qualifié (par exemple, demande ("données")). Request.servervariables est appelé implicitement pour les éléments qui ne sont pas dans request.cookies, request.form, request.querystring ou request.clientCertificate. La collection de demande.Servervariables est beaucoup plus lente que les autres collections.

Astuce 25: La mise à niveau vers les

composants système les plus récents et les plus grands est une constante, et nous vous recommandons de les mettre à niveau vers les dernières et les plus grandes configurations. Il est préférable de passer à Windows 2000 (et donc IIS 5.0, ADO 2.5, MSXML 2.5, Internet Explorer 5.0, VBScript 5.1 et JScript 5.1). Sur les ordinateurs multiprocesseurs, la mise en œuvre d'IIS 5.0 et ADO 2.5 peut considérablement améliorer les performances. Sous Windows 2000, ASP évolue bien à quatre processeurs ou plus, tandis que sous IIS 4.0, ASP ne dépasse pas deux processeurs. Plus vous utilisez de code de script et de note que vous utilisez dans votre application, plus vous ressentirez de performances après la mise à niveau vers Windows 2000.

Si vous ne pouvez pas encore passer à Windows 2000, vous pouvez passer aux dernières versions de SQL Server, ADO, VBScript et JScript, MSXML, Internet Explorer et NT 4 Service Packs. Ils améliorent tous les deux les performances et la fiabilité.

Astuce 26: Optimiser le serveur Web

Il existe différents paramètres d'optimisation IIS qui peuvent améliorer les performances du site. Par exemple, avec IIS 4.0, nous constatons souvent que l'augmentation du paramètre ASP ProcessorthReadMax (voir la documentation IIS) peut améliorer considérablement les performances, en particulier sur les sites qui ont tendance à attendre les ressources back-end (telles que les bases de données) ou d'autres produits intermédiaires (tels que comme brosses d'écran). Dans IIS 5.0, vous pouvez constater que l'activation de la sortie du thread ASP est plus efficace que de trouver un paramètre optimal pour AsprocessorthReadMax, qui est maintenant bien connu.

Pour une bonne référence, voir Optimiser IIS ci-dessous.

Les paramètres de configuration optimaux dépendent, entre autres facteurs, le code d'application, le matériel système sur lequel il s'exécute et la charge de travail du client. La seule façon de trouver les meilleurs paramètres est d'effectuer des tests de performances, dont nous discuterons dans la prochaine astuce.

Astuce 27: effectuer des tests de performance

comme nous l'avons déjà dit, les performances sont une caractéristique. Si vous souhaitez améliorer les performances de votre site, fixez un objectif de performance et améliorez progressivement jusqu'à ce que vous l'atteigniez. Non, aucun test de performance ne sera effectué. Souvent, à la fin du projet, il est trop tard pour apporter les modifications structurelles nécessaires, et votre client sera déçu. Effectuer des tests de performances dans le cadre de votre routine de test. Vous pouvez effectuer des tests de performances sur des composants individuels individuellement, tels que des pages ASP ou des objets COM, ou sur le site dans son ensemble.

De nombreuses personnes utilisent un seul navigateur pour demander une page pour tester les performances d'un site Web. Cela vous donnera l'impression que votre site est réactif, mais il ne vous dira pas réellement comment votre site fonctionne sous charge.

En règle générale, pour tester avec précision les performances, vous avez besoin d'un environnement de test dédié. Cet environnement doit inclure du matériel similaire à l'environnement de production en termes de vitesse de processeur, de nombre de processeurs, de mémoire, de disques, de configuration du réseau, etc. Deuxièmement, vous devez spécifier la charge de travail du client: combien d'utilisateurs simultanés il y a, à quelle fréquence ils font des demandes, quels types de pages sur lesquels ils cliquent, etc. Si vous n'avez pas de données sur l'utilisation réelle du site, vous devez estimer l'utilisation. Enfin, vous avez besoin d'un outil qui peut simuler les charges de travail des clients attendus. Avec ces outils, vous pouvez commencer à répondre à des questions comme "Si j'ai n utilisateurs simultanés, de combien de serveurs aurai-je besoin?" Vous pouvez également identifier les causes des goulots d'étranglement et optimiser contre eux.

Voici quelques bons outils de test de charge Web. Nous recommandons en particulier la boîte à outils Microsoft Web Application Stress (WAS). Vous permet d'enregistrer des scripts de test, puis de simuler des centaines ou des milliers d'utilisateurs accédant à un serveur Web. A été signalé un certain nombre de statistiques, y compris les demandes par seconde, la distribution du temps de réponse et le nombre d'erreurs. Is est disponible à la fois dans une interface client riche et une interface Web qui vous permet de effectuer des tests distants.

Assurez-vous de lire le guide de réglage IIS 5.0.

Astuce 28: Lire les liens de ressources

ci-dessous sont des liens vers de grandes ressources liées aux performances. Si vous souhaitez en savoir plus, lisez le développement d'applications Web évolutives.

Optimisation

des

applications Web évolutives

ont

obtenu un cache

?

Speed ​​and Optimization Resources

by Nancy Winnick Cluts

Optimizing IIS

L'art et la science du réglage du serveur Web avec Internet Information Services 5.0

Tirant Asp dans IIS 5.0,

Taping IIS 4.0 pour les sites à volume élevé par JD Meier, réglant les informations sur Internet Performances du serveur par Michael Stephenson

naviguant dans le labyrinthe des paramètres pour l'optimisation des performances du serveur Web

par Mike Moore

gérant Internet Information Server 4.0 pour les performances par Todd Wanke,

ADO et SQL Server

Top Ten Tips: Accès à SQL via ADO

Amélioration de

Les performances de votre application MDAC par

JD Meier

Envocant dans les composants d'accès aux données Microsoft de Suresh Kannan,

SQL Server: Benchmarks et guides de performances de

pour améliorer les performances des composants d'accès aux données avec IIS 4.0,

(composants d'accès aux données Microsoft ( MDAC) and ActiveX Data Objects (ADO) Performance Tips by Leland Ahlbeck,

Microsoft

SQL Server 7.0 Practical Performance Tuning and Optimization - The Server Perspective by Leland Ahlbeck,

Microsoft SQL Server 7.0 Practical Performance Tuning and Optimization - The Server Perspective by Damien Lindauer - The Perspective d'application par Damien Lindauer

Accédant à des ensembles de registres sur Internet par Dino Esposito

ASP

Component Guidelines by JD Meier

Q243548: Info: Concevoir les directives pour les composants VB sous

des

expliqués par Nancy Winnick Cluts

si heureux

Composants de serveur actifs avec ATL par

Nancy Winnick Cluts

construisant des composants de niveau moyen haute performance avec C ++ par

Neil Allain

Pages de serveurs actifs et com par Jon Flanders Apartments, par Don Box,

House of Com: Pages de serveurs actifs, par Don Box,

House of Com: Contextes, par Don Box,

House of Com: Compromis de performances de l'environnement d'exécution des composants Windows 2000, par Don Box,

Building Com composants qui profitent pleinement de Visual Basic et de Scripting , par Ivo Salmre

Component Design Principes de conception pour MTS

Dictionary Component

Créer un objet de cache de page, par Robert Coleridge

abrivant l'objet Dictionnaire: l'équipe ASP crée un objet de table de recherche, par Robert Carter

Caprock Dictionary

état de session

de dictionnaire de ses composants.

Q175167: Howto: Valeurs persistantes sans sessions

Q157906: HowTo: Comment maintenir l'état à travers les pages avec

des comportements de persistance basés sur XML à VBBScript corriger les maux de tête de la ferme Web par Aaron Skonnard

House of Com: Programmation sans état par Don Box

Performance and Scalilabilité

Blueprint pour la construction Web Sites utilisant les

Performances et les tueurs d'évolutivité du serveur de plate-forme ADN Windows Microsoft Windows, par George Reilly

Microsoft Visual Studio Scalibability Center

Fitch & Mather Stocks 2000

Taping L'application FMSTOCKS Application

Visual Basic Applications Applications Visual de base, par Ken Spencer

Duwamish

Book Et comment les empêcher par Gary Geiger et Jon Pulsipher

de

HTML statique aux agriculteurs Web à haute performance par Shawn Bice

Microsoft Application Stress Tool

Je

ne peux pas le souligner suffisamment - Test de charge

des kit de performances

dans des applications distribuées à l'aide de Visual Studio Analyzer, par Mai-Lan Tomsen

Bibliography

Professional Active Server Pages 3.0, Wrox Press (en particulier le chapitre 26: Optimisation des performances ASP, George Reilly avec Matthew Gibbs).

Microsoft Internet Information Services 5.0 Guide de ressources (avec Kit Windows 2000 Server Resource Kit), Microsoft Press.

Microsoft Internet Information Server Resource Kit (pour IIS 4.0), Microsoft Press.

Programmation des applications distribuées avec COM et Microsoft Visual Basic 6.0, par Ted Pattison, Microsoft Press.

COM efficace, par Don Box, Keith Brown, Tim Ewald et Chris vend;

Développer la convivialité sur le Web: la pratique de la simplicité, par Jakob Nielsen, New Riders.

ASP Web SitesMicrosoft

TechNet pour IIS

Learnasp.com

4guysfromrolla.com

15secondes.com

asptoday.com

asp101.com

asplists.com. De nombreuses listes de diffusion professionnelles incluent:

Code rapide!
ASP a avancé
Pas la gestion nouvelle
Évolutivité
Composants de base visuels
Xml
Bâtiment des composants C ++ / ATL
Useit.com: Webiabilité Web

ASP Style

ASP meilleures pratiques par George Reilly

ASP Lesons rapides par Charles Carroll

Planning pour ASP John Meade

XML

par JD Meier

dans les performances XML par Chris Lovett

Inside MSXML3 Performance par Chris Lovett