Configuration d’IIS

les applications pour s’exécuter de manière isolée et en encourageant
les développeurs à  travailler séparément.
On peut en outre désactiver le support des sessions et préserver les ressources
des applications en optimisant le cache de votre moteur de script et le cache
ASP. Certaines de ces modifications, telles que la modification des paramètres
de bufferisation, ne fonctionnent qu’avec les applications ASP. Si votre site
Web est statique, il n’est pas possible d’utiliser la bufferisation ou d’autres
réglages qui affectent les applications ASP.

On peut améliorer les performances du système en activant la bufferisation des
applications. Lorsque la bufferisation est active, IIS traite chaque page Web
complètement avant de transmettre les données. Lorsqu’elle est désactivée (paramétrage
par défaut d’IIS 4.0), IIS produit les pages à  mesure que vous générez du HTML.
Ainsi, lorsqu’un développeur insère une étiquette HTML dans une page ou utilise
Response.Write pour générer une sortie, cette dernière est immédiatement ralentie
car IIS traite la page ligne par ligne. De plus, comme le browser n’accepte pas
les changements après qu’il ait reçu un en-tête HTML, les développeurs ne peuvent
pas faire d’opération qui affecte les en-tête HTML comme par exemple utiliser
Response.Direct.

Pour activer la bufferisation, activez la propriété dans le Gestionnaire de service
Internet. Ouvrez le et trouvez le dossier que vous voulez modifier. Cliquez à 
droite sur le dossier et sélectionnez Propriétés dans le menu contextuel. Cliquez
sur Configurer et sélectionnez l’onglet des options d’applications de l’écran
3. Cochez la case activant la bufferisation et cliquez sur OK. Les développeurs
n’auront pas à  modifier l’application ou d’apporter quelque changement que ce
soit, sauf s’ils veulent changer l’aspect de l’application. Les pages seront traitées
complètement, ce qui fait que lorsque les développeurs travaillent sur des pages
contenant beaucoup de traitement, ils peuvent utiliser périodiquement la méthode
dite du Flush pour forcer une sortie sous forme de flux HTML.

Le débogage ASP est utile pour tracer les erreurs dans les applications mais peut
dégrader les performances. L’option d’activation du débogage ASP des scripts du
serveur est dans l’onglet de debugging des pages de propriétés de configuration
des applications. Les développeurs peuvent activer ces paramètres, puis déboguer
le code ASP avec Microsoft Visual InterDev. Lorsque le débogage est activé, le
Gestionnaire de service Internet fait de l’application une application hors-processus.
Ce type d’applications tourne dans son propre espace mémoire, ce qui dégrade les
performances de façon significative et peut causer le plantage d’IIS.

Dernier point, encouragez les développeurs à  utiliser une association entre les
serveurs de développement et leur propre poste de travail lorsqu’ils écrivent
des applications. Les développeurs peuvent utiliser leurs propres postes de travail
(avec NT Workstation ou Server, IIS et Visual InterDev) pour créer et modifier
les applications Web. Ensuite, les développeurs peuvent copier les applications
sur un serveur de développement sur lequel d’autres développeurs pourront les
utiliser. L’approche consistant à  développer sur son poste de travail permet aux
développeurs de créer et déboguer leurs applications sans affecter d’autres développeurs
ou utilisateurs des applications de production.

Ainsi, les développeurs sont libres de mettre en oeuvre et tester les modifications
qu’ils veulent sur leur poste de travail sans affecter le fonctionnement des serveurs.

Désactivez le support de l’état de session. Désactiver le support de l’état de
session est une autre modification que l’on peut faire dans les pages de propriété
du Gestionnaire de services Internet afin de réduire la charge du système. Ne
faites ce changement qu’après en avoir informé vos développeurs et avoir déterminé
si vos applications se servent de la fonction. Les Webmasters ne peuvent pas le
faire de leur propre chef car les développeurs d’application peuvent y avoir recours
dans leurs applications.
Avant de désactiver le support de l’état de session, assurez-vous que les développeurs
d’applications suppriment les codes événement Session_OnStart et Session_OnEnd
de Global.asa et toute utilisation des variables de session de leurs applications.
Vous pouvez alors désactiver la fonction comme dans l’écran 3.Le support de l’état
de session permet aux développeurs de pister les informations sur l’utilisateur
dans une application. Il fonctionne en envoyant des cookies aux browsers des utilisateurs.

Chaque fois qu’un utilisateur visite une page, ASP peut retrouver le cookie et
vérifier les informations d’état de l’utilisateur. Lorsque le support d’état de
session est activé, l’événement Session_OnStart de Global.asa se produit la première
fois qu’un utilisateur visite l’application. Lorsque la session se termine, l’événement
Session_OnEnd se produit. Ces événements sont des raccordements que les développeurs
peuvent utiliser comme triggers pour des traitements spécifiques à  l’utilisateur
dans l’application.

Lorsqu’une application utilisant le support de l’état de session est lancée, le
système crée un objet de session, ce qui augmente la charge sur le serveur. Si
le nombre d’utilisateurs exploitant l’application augmente, cette charge augmente
également pour gérer les sessions. Les développeurs utilisent également les variables
de session pour stocker différents types d’information. Plus un développeur stocke
de données dans les variables de session, plus cette variable utilise de mémoire.

En désactivant le support de l’état de session, non seulement on diminue la charge
sur le serveur, mais on améliore également les performances des pages avec de
multiples objets tels que les frames. Internet Explorer (IE) 5.0 et 4.0 utilisent
des threads distincts pour traiter les pages comportant plusieurs threads. Lorsque
le support de l’état de session est désactivé, les utilisateurs obtiennent de
meilleures performances car IE traite les pages simultanément, restituant ainsi
les pages plus rapidement. Si le support de l’état de session est opérationnel,
IIS désactive ce traitement multithread et chaque page de l’ensemble de frames
est traité en séquence sur le serveur.

Le support de l’état de session peut également ne pas fonctionner dans certaines
situations en cas d’équilibrage des charges. On accède généralement aux serveurs
IIS en passant par un système d’équilibrage des charges tel que Microsoft Windows
Load Balancing Server. Si le système d’équilibrage de charges utilise un partage
aléatoire simple des systèmes, les utilisateurs passent d’un serveur à  un autre
lorsqu’ils naviguent dans une application avec leur browser Web. Si un utilisateur
lance une application sur un serveur et que le système d’équilibrage de charges
reroute l’utilisateur sur un autre serveur au milieu de la session, les variables
de session du premier serveur ne seront pas transférées sur le deuxième. Résultat,
l’application ne fonctionnera pas correctement.
Certains systèmes planificateurs de tâches ou d’équilibrage de charge prennent
en charge l’état de session et dirigeant les utilisateurs sur le même serveur
chaque fois qu’ils retournent vers l’application au cours d’une session.