Les développeurs ASP s'efforcent continuellement d'obtenir de meilleures performances et une meilleure évolutivité dans leurs projets de conception. Heureusement, il existe de nombreux livres et sites qui offrent de bons conseils dans ce domaine. Cependant, ces suggestions sont basées sur des conclusions tirées de la structure du travail de la plateforme ASP et il n'existe aucune mesure quantitative de l'amélioration réelle des performances. Étant donné que ces recommandations nécessitent un codage plus complexe et rendent le code moins lisible, les développeurs doivent déterminer si l'amélioration des performances de leurs applications ASP en vaut le coût, sans voir les résultats réels.
Cet article est divisé en deux parties. Je présenterai quelques résultats de tests de performances pour aider les développeurs à déterminer si une initiative particulière vaut la peine non seulement pour les projets futurs, mais également pour mettre à jour le projet d'origine. Dans la première partie, je passerai en revue quelques problèmes fondamentaux du développement ASP. Dans la deuxième partie, vous aborderez l'optimisation de certaines fonctions ADO et la comparaison de leurs résultats avec des pages ASP qui appellent des objets VB COM pour exécuter les mêmes fonctions ADO. Les résultats sont révélateurs et parfois surprenants.
Dans cet article, nous répondrons aux questions suivantes :
* Quelle est la manière la plus efficace d'écrire du contenu généré par ASP dans le flux de réponse ?
* Le tampon doit-il être activé ?
* Devriez-vous envisager d'ajouter des commentaires à votre code ASP ?
* La langue par défaut doit-elle être définie explicitement pour la page ?
* L'état de session doit-il être fermé s'il n'est pas nécessaire ?
* La logique de script doit-elle être placée dans les sous-programmes et les zones de fonctions ?
* Quelles sont les implications de l'utilisation des fichiers d'inclusion ?
* Quel type de charge est imposé lors de la gestion des erreurs ?
* La configuration d'un gestionnaire de contexte a-t-elle un impact sur les performances ?
Tous les tests ont été effectués à l'aide du Web Application Focus Tool (WAST) de Microsoft, un outil gratuit disponible ici. J'ai créé un script de test simple à l'aide de WAST qui appelait à plusieurs reprises les tests de page ASP décrits ci-dessous (plus de 70 000 fois chacun). Le temps de réponse est basé sur le temps total moyen du dernier octet (TTLB), qui correspond au temps écoulé entre le moment de la requête initiale et le moment où l'outil reçoit le dernier bit de données du serveur. Notre serveur de test est un Pentium 166 avec 196 Mo de RAM et le client est un Pentium 450 avec 256 Mo de RAM. Vous pourriez penser que les performances de ces machines ne sont pas très avancées, mais n'oubliez pas que nous ne testons pas la capacité du serveur, nous testons simplement le temps nécessaire au serveur pour traiter une page à la fois. Les machines n'effectuent aucun autre travail pendant le test. Les scripts de test WAST, les rapports de test et toutes les pages de test ASP sont inclus dans le fichier ZIP pour que vous puissiez les examiner et les tester vous-même.
Quelle est la manière la plus efficace d’écrire le contenu généré par ASP dans le flux de réponse ?
L'une des principales raisons d'utiliser ASP est de générer du contenu dynamique sur le serveur. Le point de départ évident de nos tests est donc de déterminer la manière la plus appropriée d’envoyer du contenu dynamique dans le flux de réponse. Parmi les nombreuses options, deux sont les plus élémentaires : l'une consiste à utiliser des balises ASP en ligne et l'autre à utiliser l'instruction Response.Write.
Pour tester ces options, nous avons créé une simple page ASP dans laquelle nous avons défini quelques variables puis inséré leurs valeurs dans un tableau. Bien que cette page soit simple et peu pratique, elle nous permet d'isoler et de tester certains problèmes individuels.
Utilisation des balises en ligne ASP
Le premier test consiste à utiliser la balise ASP en ligne < %= x % >, où x est une variable affectée. Cette méthode est de loin la plus simple à mettre en œuvre et conserve la partie HTML de la page dans un format facile à lire et à gérer.
＜% OPTION EXPLICITE
Dim Prénom
DimLastName
Faible milieuInitial
Dim Adresse
Ville sombre
État sombre
FaibleNuméro de téléphone
Faxer le numéro de fax
Faible e-mail
DimDate de naissance
Prénom = Jean
MilieuInitial = Q
Nom = Public
Adresse = 100, rue Main
Ville = New York
État = New York
Numéro de téléphone = 1-212-555-1234
Numéro de fax = 1-212-555-1234
E-mail = [email protected]
Date de naissance = 1/1/1950
%>
＜HTML＞
＜TÊTE＞
＜ TITRE ＞Test de réponse ＜ / TITRE ＞
＜ /TÊTE ＞
＜CORPS＞
＜ H1 ＞Test de réponse ＜ /H1 ＞
＜TABLEAU ＞
＜ tr ＞＜ td ＞＜ b ＞Prénom :＜ /b ＞＜ /td ＞＜ td ＞＜ %= Prénom % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Middle Initial:＜ /b ＞＜ /td ＞＜ td ＞＜ %= MiddleInitial % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Nom :＜ /b ＞＜ /td ＞＜ td ＞＜ %= Nom % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Adresse :＜ /b ＞＜ /td ＞＜ td ＞＜ %= Adresse % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Ville:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Ville % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞État :＜ /b ＞＜ /td ＞＜ td ＞＜ %= État % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Numéro de téléphone :＜ /b ＞＜ /td ＞＜ td ＞＜ %= Numéro de téléphone % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Numéro de fax :＜ /b ＞＜ /td ＞＜ td ＞＜ %= Numéro de fax % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞EMail:＜ /b ＞＜ /td ＞＜ td ＞＜ %= EMail % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Date de naissance :＜ /b ＞＜ /td ＞＜ td ＞＜ %= Date de naissance % ＞＜ /td ＞＜ /tr ＞
＜ /TABLE ＞
＜ /CORPS ＞
＜ /HTML ＞
Le code complet de /app1/response1.asp
Meilleur précédent (vitesse de réponse) = 8,28 ms/page
Utilisez l'instruction Response.Write sur chaque ligne HTML
La plupart des meilleurs documents d’apprentissage recommandent d’éviter la méthode précédente. La raison principale en est que, lors du processus de sortie de la page et de traitement de la page pour imposer une latence, si le serveur Web doit effectuer une conversion entre l'envoi de HTML brut et le traitement du script, un problème appelé changement de contexte se produit. Lorsque la plupart des programmeurs entendent cela, leur première réaction est d'envelopper chaque ligne de code HTML brut dans une fonction Response.Write.
…
Réponse.Write(＜html＞)
Réponse.Write(＜tête＞)
Response.Write(＜titre＞Test de réponse＜/titre＞)
Réponse.Write(＜/head＞)
Réponse.Write(＜corps＞)
Response.Write(＜h1＞Test de réponse＜/h1＞)
Réponse.Write(＜table＞)
Response.Write (＜ tr ＞＜ td ＞＜ b ＞Prénom :＜ /b ＞＜ /td ＞＜ td ＞ & Prénom & ＜ /td ＞＜ /tr ＞)
Response.Write (＜ tr ＞＜ td ＞＜ b ＞Middle Initial:＜ /b ＞＜ /td ＞＜ td ＞ & MiddleInitial & ＜ /td ＞＜ /tr ＞)
… <
Fragment de /app1/response2.asp
Meilleur précédent (vitesse de réponse) = 8,28 ms/page
Temps de réponse = 8,08 ms/page
Différence = -0,20 ms (réduction de 2,4 %)
Nous pouvons voir que le gain de performances résultant de l'utilisation de cette approche est très faible par rapport à l'utilisation du balisage en ligne, peut-être parce que la page charge le serveur avec un ensemble de petits appels de fonction. Le plus gros inconvénient de cette approche est que, puisque le code HTML est désormais intégré au script, le code du script devient plus verbeux et plus difficile à lire et à maintenir.
Utiliser les fonctions wrapper
La découverte la plus décourageante lorsque l’on essaie d’utiliser l’approche d’instruction Response.Write est peut-être que la fonction Response.Write ne peut pas placer un CRLF à la fin de chaque ligne. Ainsi, lorsque vous lisez le code source à partir du navigateur, le code HTML parfaitement présenté ne comporte désormais qu'une seule ligne sans fin. Je pense que votre prochaine découverte pourrait être encore plus horrible : il n'y a pas de fonction sœur Writeln dans l'objet Response. Ainsi, une réaction évidente consiste à créer une fonction wrapper pour la fonction Response.Write afin d’ajouter un CRLF à chaque ligne.
…
writeCR(＜ tr ＞＜ td ＞＜ b ＞Prénom :＜ /b ＞＜ /td ＞＜ td ＞ & Prénom & ＜ /td ＞＜ /tr ＞)
…
SUB écrireCR(str)
Réponse.Write(str & vbCRLF)
FIN SOUS
Fragment de /app1/response4.asp
Meilleur précédent (vitesse de réponse) = 8,08 ms/page
Temps de réponse = 10,11 ms/page
Différence = +2,03 ms (augmentation de 25,1 %)
Bien entendu, étant donné que cette approche double effectivement le nombre d’appels de fonctions, son impact sur les performances est important et doit être évité à tout prix. Ironiquement, CRLF ajoute également 2 octets par ligne au flux réactif, que le navigateur n'a pas besoin de restituer sur la page. Tout ce qu'un HTML bien formaté fait, c'est permettre à vos concurrents de lire plus facilement votre code source HTML et de comprendre votre conception.
Concaténer une réponse consécutive. Écrire en une seule instruction
Indépendamment de nos tests précédents avec les fonctions wrapper, la prochaine étape logique consiste à extraire toutes les chaînes des instructions Response.Write distinctes et à les concaténer en une seule instruction, réduisant ainsi le nombre d'appels de fonction, améliorant considérablement les performances de la page.
…
Réponse.Write(＜html＞&_
＜ tête ＞ & _
＜titre＞Test de réponse＜/titre＞ & _
＜ /tête ＞ & _
＜corps＞ & _
＜ h1 ＞Test de réponse＜ /h1 ＞ & _
＜ tableau ＞ & _
＜ tr ＞＜ td ＞＜ b ＞Prénom :＜ /b ＞＜ /td ＞＜ td ＞ & Prénom & ＜ /td ＞＜ /tr ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞Date de naissance :＜ /b ＞＜ /td ＞＜ td ＞ & Date de naissance & ＜ /td ＞＜ /tr ＞ & _
＜ /table ＞ & _
＜ /corps ＞ & _
＜ /html ＞)
Fragment de /app1/response3.asp
Meilleur précédent (vitesse de réponse) = 8,08 ms/page
Temps de réponse = 7,05 ms/page
Différence = -1,03 ms (réduction de 12,7 %)
Actuellement, c'est la configuration la plus optimisée.
Concaténer une réponse consécutive. Écrire en une seule instruction, en ajoutant un CRLF à la fin de chaque ligne
En considération de ceux qui ont besoin que leur code source soit impeccable depuis un navigateur, j'ai utilisé la constante vbCRLF pour insérer des retours chariot à la fin de chaque ligne dans le test précédent et je l'ai réexécuté.
…
Réponse.Write(＜html＞&vbCRLF&_
＜ tête ＞ & vbCRLF & _
＜ titre ＞Test de réponse＜ /titre ＞ & vbCRLF & _
＜ /tête ＞ & vbCRLF & _
…
Fragment de /app1/response5.asp
Meilleur précédent (vitesse de réponse) = 7,05 ms/page
Temps de réponse = 7,63 ms/page
Différence = +0,58 ms (augmentation de 8,5 %)
Le résultat est une légère diminution des performances, peut-être en raison de la concaténation supplémentaire et de l'augmentation du nombre de caractères.
Examen et observation
Certaines règles peuvent être tirées des tests précédents sur la sortie ASP :
* Évitez l'utilisation excessive d'ASP en ligne.
* Concaténez toujours les instructions Response.Write consécutives en une seule instruction.
* N'utilisez jamais de fonctions wrapper autour de Response.Write pour ajouter CRLF.
* Si la sortie HTML doit être formatée, ajoutez CRLF directement dans l'instruction Response.Write.
Le tampon doit-il être activé ?
Démarrer le tampon via un script
En incluant Response.Buffer=True en haut du script ASP, IIS mettra en cache le contenu de la page.
＜% OPTION EXPLICITE
Réponse.Buffer = vrai
Dim Prénom
…
Fragment de /app1/buffer__1.asp
Meilleur précédent (temps de réponse) = 7,05 ms/page
Temps de réponse = 6,08 ms/page
Différence = -0,97 ms (réduction de 13,7 %)
Les performances ont été grandement améliorées. Mais attendez, il y a quelque chose de mieux.
Tampon de démarrage via la configuration du serveur
Bien que le tampon soit activé par défaut dans IIS 5.0, il doit être activé manuellement dans IIS 4.0. Recherchez maintenant la boîte de dialogue Propriétés du site et sélectionnez le bouton Configurer dans l'onglet Répertoire de base. Sélectionnez ensuite activer la mise en mémoire tampon sous Options de l'application. Pour ce test, l'instruction Response.Buffer a été déplacée du script.
Meilleur précédent = 7,05 ms/page
Temps de réponse = 5,57 ms/page
Différence = -1,48 ms (réduction de 21,0 %)
Actuellement, il s’agit de la réponse la plus rapide que nous ayons jamais eue, 21 % de moins que notre précédent meilleur temps de réponse. Désormais, nos futurs tests utiliseront ce temps de réaction comme valeur de référence.
Examen et observation
Les tampons sont un excellent moyen d'améliorer les performances, il est donc nécessaire de définir les tampons sur les valeurs par défaut du serveur. Si, pour une raison quelconque, la page ne peut pas exécuter correctement le tampon, utilisez simplement la commande Response.Buffer=False. L'un des inconvénients des tampons est que l'utilisateur ne voit rien du serveur tant que la page entière n'a pas été traitée. Par conséquent, lors du traitement de pages complexes, il est judicieux d'appeler occasionnellement Response.Flush pour mettre à jour l'utilisateur.
Nous avons maintenant ajouté une règle supplémentaire : activez toujours la mise en mémoire tampon via les paramètres du serveur.
Devez-vous envisager d’ajouter des commentaires à votre code ASP ?
La plupart des développeurs HTML savent qu'inclure des commentaires HTML est une mauvaise idée, d'une part cela augmente la taille des données transférées, et d'autre part ils fournissent simplement aux autres développeurs des informations sur l'organisation de votre page. Mais qu’en est-il des commentaires sur les pages ASP ? Ils ne quittent jamais le serveur, mais ils augmentent la taille de la page et doivent donc être divisés à l'aide d'ASP.
Dans ce test, nous avons ajouté 20 commentaires de 80 caractères chacun, pour un total de 1 600 caractères.
＜% OPTION EXPLICITE
'------------------------------------------------ - ---------------------------------
…20 lignes…
'------------------------------------------------ - ---------------------------------
Dim Prénom
…
Fragment /app2/comment_1.asp
Ligne de base = 5,57 ms/page
Temps de réponse = 5,58 ms/page
Différence = +0,01 ms (augmentation de 0,1 %)
Les résultats du test étaient étonnants. Bien que les commentaires soient presque deux fois plus longs que le fichier lui-même, leur présence n’a pas d’impact majeur sur les temps de réponse. Nous pouvons donc suivre les règles suivantes :
Tant qu'elles sont utilisées modérément, les annotations ASP ont peu ou pas d'impact sur les performances.
La langue par défaut doit-elle être définie explicitement pour la page ?
IIS gère VBScript par défaut, mais je constate que dans la plupart des cas, le langage est explicitement défini sur VBScript à l'aide de l'instruction <%@LANGUAGE=VBSCRIPT%>. Notre prochain test examinera l’impact de la présence de cette déclaration sur les performances.
＜ %@ LANGUE=VBSCRIPT % ＞
＜% OPTION EXPLICITE
Dim Prénom
…
Fragment /app2/langue1.asp.
Ligne de base = 5,57 ms/page
Temps de réponse = 5,64 ms/page
Différence = +0,07 ms (augmentation de 1,2 %)
Comme vous pouvez le constater, l'inclusion de déclarations de langue a un léger impact sur les performances. donc:
* Définissez la configuration linguistique par défaut du serveur pour qu'elle corresponde à la langue utilisée sur le site.
* Ne définissez pas de déclaration de langue sauf si vous utilisez une langue autre que celle par défaut.
L'état de session doit-il être désactivé s'il n'est pas nécessaire ?
Il existe de nombreuses raisons d'éviter d'utiliser le contexte de session IIS, et celles-ci pourraient constituer leur propre article. La question à laquelle nous essayons de répondre maintenant est de savoir si la fermeture du contexte de session lorsqu'il n'est pas nécessaire à la page contribuera à améliorer les performances. Théoriquement, cela devrait être oui, car il n'est alors pas nécessaire d'utiliser la page pour instancier le contexte de session.
Comme pour le tampon, il existe deux manières de configurer l'état de la session : via des scripts et via les paramètres du serveur.
Contexte de fermeture de session via un script
Pour ce test, pour fermer le contexte Session dans la page, j'ai ajouté une déclaration d'état de session.
＜ %@ ENABLESESSIONSTATE = FAUX % ＞
＜% OPTION EXPLICITE
Dim Prénom
…
Fragment /app2/session_1.asp.
Ligne de base = 5,57 ms/page
Temps de réponse = 5,46 ms/page
Différence = -0,11 ms (diminution de 2,0 %)
De bons progrès ont été réalisés grâce à un si petit effort. Regardez maintenant la deuxième partie.
Fermez le contexte de session via la configuration du serveur
Pour fermer le contexte Session sur le serveur, accédez à la boîte de dialogue Propriétés du site. Sélectionnez le bouton Configuration dans l'onglet Répertoire personnel. Décochez ensuite Activer l'état de la session sous Options de l'application. Nous exécutons le test sans l'instruction ENABLESESSIONSTATE.
Ligne de base = 5,57 ms/page
Temps de réponse = 5,14 ms/page
Différence = -0,43 ms (réduction de 7,7 %)
Il s’agit d’une autre amélioration significative des performances. Par conséquent, notre règle devrait être la suivante : fermez toujours l’état de session au niveau de la page ou de l’application lorsqu’il n’est pas nécessaire.
L'utilisation d'Option Explicit modifiera-t-elle considérablement les performances ?
Définissez Option Explicit en haut d’une page ASP pour exiger que toutes les variables soient déclarées sur la page avant utilisation. Il y a deux raisons à cela. Premièrement, les applications peuvent traiter l’accès aux variables plus rapidement. Deuxièmement, cela nous évite d’utiliser accidentellement et incorrectement les noms de variables. Dans ce test, nous supprimons la référence Option Explicit et la déclaration Dim de la variable.
Ligne de base = 5,57 ms/page
Temps de réponse = 6,12 ms/page
Différence = +0,55 msec (augmentation de 9,8 %),
Même si certaines lignes de code ont été supprimées de la page, les temps de réponse ont quand même augmenté. Ainsi, même si l’utilisation d’Option explicit prend parfois du temps, elle a un effet significatif sur les performances. Nous pouvons donc ajouter une autre règle : utilisez toujours Option explicit dans VBScript.
La logique de script doit-elle être placée dans les sous-programmes et les zones de fonctions ?
L'utilisation de fonctions et de sous-programmes est un bon moyen d'organiser et de gérer le code, en particulier lorsqu'une zone de code est utilisée plusieurs fois sur la page. L'inconvénient est qu'il ajoute un appel de fonction supplémentaire au système qui fait le même travail. Un autre problème avec les sous-programmes et les fonctions est la portée des variables. En théorie, il est plus efficace de spécifier des variables dans un domaine fonctionnel. Voyons maintenant comment ces deux aspects entrent en jeu.
Déplacez l'instruction Response.Write dans un sous-programme
Ce test déplace simplement l'instruction Response.Write dans une zone de sous-programme.
…
APPELER writeTable()
SUB writeTable()
Réponse.Write(＜html＞&_
＜ tête ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞EMail:＜ /b ＞＜ /td ＞＜ td ＞ & EMail & ＜ /td ＞＜ /tr ＞ & _
＜ tr ＞＜ td ＞＜ b ＞Date de naissance :＜ /b ＞＜ /td ＞＜ td ＞ & Date de naissance & ＜ /td ＞＜ /tr ＞ & _
＜ /table ＞ & _
＜ /corps ＞ & _
＜ /html ＞)
FIN SOUS
Fragment /app2/function1.asp
Ligne de base = 5,57 ms/page
Temps de réponse = 6,02 ms/page
Différence = +0,45 ms (augmentation de 8,1 %)
Comme prévu, les appels de sous-programmes imposent une surcharge supplémentaire à la page.
Déplacez tous les scripts dans des sous-programmes
Dans ce test, l'instruction Response.write et les déclarations de variables sont déplacées dans une zone de sous-programme.
＜% OPTION EXPLICITE
APPELER writeTable()
SUB writeTable()
Dim Prénom
…
DimDate de naissance
Prénom = Jean
…
Date de naissance = 1/1/1950
Réponse.Write(＜html＞&_
＜ tête ＞ & _
＜titre＞Test de réponse＜/titre＞ & _
＜ /tête ＞ & _
＜corps＞ & _
＜ h1 ＞Test de réponse＜ /h1 ＞ & _
＜ tableau ＞ & _
＜ tr ＞＜ td ＞＜ b ＞Prénom :＜ /b ＞＜ /td ＞＜ td ＞ & Prénom & ＜ /td ＞＜ /tr ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞Date de naissance :＜ /b ＞＜ /td ＞＜ td ＞ & Date de naissance & ＜ /td ＞＜ /tr ＞ & _
＜ /table ＞ & _
＜ /corps ＞ & _
＜ /html ＞)
FIN SOUS
Fragment /app2/function2.asp
Ligne de base = 5,57 ms/page
Temps de réponse = 5,22 ms/page
Différence = -0,35 ms (réduction de 6,3 %)
Très intéressant ! Bien que le déplacement de variables dans la portée de la fonction ajoute un appel de fonction supplémentaire, cela améliore en réalité les performances. Nous pouvons ajouter les règles suivantes :
* Sur une page, si le code doit être utilisé plusieurs fois, placez le code dans une zone de fonction.
* Le cas échéant, déplacez les déclarations de variables dans la portée de la fonction.
Quelles sont les implications de l’utilisation des fichiers include ?
Une caractéristique importante de la programmation ASP est l'inclusion de code provenant d'autres pages. Grâce à cette fonctionnalité, les programmeurs peuvent partager des fonctions sur plusieurs pages, ce qui facilite la maintenance du code. L'inconvénient est que le serveur doit assembler la page à partir de plusieurs sources. Vous trouverez ci-dessous deux tests utilisant des fichiers Inclure.
Inclure des fichiers à l'aide du code en ligne
Dans ce test, un petit morceau de code a été déplacé dans un fichier Include :
＜% OPTION EXPLICITE
Dim Prénom
…
DimDate de naissance
Prénom = Jean
…
Date de naissance = 1/1/1950
%>
＜ !-- #include file=inc1.asp -- ＞
Fragment /app2/include_1.asp
Ligne de base = 5,57 ms/page
Temps de réponse = 5,93 ms/page
Différence = +0,36 ms (augmentation de 6,5 %)
Ce n’est pas surprenant. La charge utile est formée à l’aide de fichiers Include.
Utilisez Inclure les fichiers dans la zone de fonction
Ici, le code est encapsulé dans un sous-programme dans un fichier Include. La référence Include est faite en haut de la page et appelle le sous-programme à l'emplacement approprié dans le script ASP.
＜% OPTION EXPLICITE
Dim Prénom
…
DimDate de naissance
Prénom = Jean
…
Date de naissance = 1/1/1950
APPELER writeTable()
%>
＜ !-- #include file=inc2.asp -- ＞
Fragment /app2/include_2.asp
Ligne de base = 5,57 ms/page
Temps de réponse = 6,08 ms/page
Différence = +0,51 ms (augmentation de 9,2 %)
Cela a un impact plus important sur les performances que les appels de fonctions. Donc : utilisez les fichiers Inclure uniquement lorsque le code est partagé entre les pages.
Quelle charge est créée lors de la gestion des erreurs ?
La gestion des erreurs est nécessaire pour toutes les applications réelles. Dans ce test, le gestionnaire d’erreurs est appelé en appelant la fonction On Error Resume Next.
＜% OPTION EXPLICITE
En cas d'erreur, reprendre ensuite
Dim Prénom
…
Fragment /app2/error_1.asp
Ligne de base = 5,57 ms/page
Temps de réponse = 5,67 ms/page
Différence = 0,10 ms (augmentation de 1,8 %)
Comme vous pouvez le constater, la gestion des erreurs a un prix. Nous pouvons suggérer ce qui suit : Utilisez les gestionnaires d'erreur uniquement lorsque quelque chose se produit et échappe à votre capacité à tester ou à contrôler. Un exemple simple consiste à utiliser des objets COM pour accéder à d'autres ressources, telles que des objets ADO ou FileSystem.
La configuration d'un gestionnaire de contexte a-t-elle un impact sur les performances ?
Lorsqu'une erreur se produit, la définition d'un gestionnaire de contexte sur la page permet au script d'inverser l'action. Ceci est défini à l’aide d’une instruction de traitement sur la page.
＜ %@ TRANSACTION = REQUIS % ＞
＜% OPTION EXPLICITE
Dim Prénom
…
Fragment /app2/transact1.asp
Ligne de base = 5,57 ms/page
Temps de réponse = 13,39 ms/page
Différence = +7,82 ms (augmentation de 140,4 %)
ah ! C’est vraiment le résultat le plus dramatique. Veuillez donc noter la règle suivante : utilisez le contexte de traitement uniquement lorsque deux opérations ou plus sont effectuées comme une unité.
en conclusion
Ce qui est important dans la première partie de cet article, c’est l’accumulation de beaucoup de petites choses. Pour mettre en évidence ce problème, j'ai mis en place un test final où j'ai fait toutes les choses que nous avions testées auparavant et qui semblaient inoffensives mais qui avaient en réalité un mauvais effet. J'ai inclus un tas d'instructions Response.Write, désactivé le tampon, défini la langue par défaut, supprimé la référence Option Explicit et initialisé le gestionnaire d'erreurs.
＜ %@ LANGUE=VBSCRIPT % ＞
< %
En cas d'erreur, reprendre ensuite
Prénom = Jean
…
Date de naissance = 1/1/1950
Réponse.Write(＜html＞)
Réponse.Write(＜tête＞)
Response.Write(＜titre＞Test de réponse＜/titre＞)
Réponse.Write(＜/head＞)
Réponse.Write(＜corps＞)
Response.Write(＜h1＞Test de réponse＜/h1＞)
Réponse.Write(＜table＞)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Prénom :＜ /b ＞＜ /td ＞＜ td ＞ &_
Prénom & ＜ /td ＞＜ /tr ＞)
…
Réponse.Écrire (＜ tr ＞＜ td ＞＜ b ＞Date de naissance :＜ /b ＞＜ /td ＞＜ td ＞ &_
Date de naissance & ＜ /td ＞＜ /tr ＞)
Réponse.Write(＜/table＞)
Réponse.Write(＜/body＞)
Réponse.Write(＜/html＞)
%>
Fragment /app2/final_1.asp
Ligne de base = 5,57 ms/page
Temps de réponse = 8,85 ms/page
Différence = +3,28 ms (augmentation de 58,9 %)
Cela peut paraître évident, mais il est plus important de comprendre que le code que nous plaçons sur la page a un impact sur les performances. De petits changements sur la page peuvent parfois augmenter considérablement les temps de réponse.
Résumé des règles
* Évitez l'utilisation excessive d'ASP en ligne.
* Concaténez toujours les instructions Response.Write consécutives en une seule instruction.
* N'utilisez jamais de fonctions wrapper autour de Response.Write pour ajouter CRLF.
* Si la sortie HTML doit être formatée, ajoutez CRLF directement dans l'instruction Response.Write.
* Activez toujours la mise en mémoire tampon via les paramètres du serveur.
* Tant qu'elles sont utilisées modérément, les annotations ASP ont peu ou pas d'impact sur les performances.
* Définissez la configuration linguistique par défaut du serveur pour qu'elle corresponde à la langue utilisée sur le site.
* Ne définissez pas de déclaration de langue sauf si vous utilisez une langue autre que celle par défaut.
* Utilisez toujours Option explicite dans VBScript.
* Désactivez toujours l'état de session au niveau de la page ou de l'application lorsque vous n'en avez pas besoin.
* Utilisez Inclure les fichiers uniquement lorsque le code est partagé entre les pages.
* Sur une page, si le code doit être utilisé plusieurs fois, placez le code dans une zone de fonction.
* Le cas échéant, déplacez les déclarations de variables dans la portée de la fonction.
* Utilisez les gestionnaires d'erreur uniquement si des conditions dépassant les capacités du test ou du contrôle se produisent.
* Utilisez le traitement contextuel uniquement lorsque deux opérations ou plus sont effectuées comme une unité.
Avec le recul, un certain nombre de questions peuvent servir de lignes directrices générales :
* Évitez la redondance : ne définissez pas de propriétés déjà définies par défaut.
* Limiter le nombre d'appels de fonctions.
* Réduisez la portée du code.