Web Gardens

que vous
avez indiqué pour le pool. Ainsi, si vous
définissez un pool d’applications ave
trois processus de travail, après trois requêtes,
vous verrez trois instances de w3wp fonctionnant sur
votre serveur, toutes délivrant le même contenu. IIS 6.0 établit
les connexions suivantes de manière circulaire vis-à -vis
des processus de travail dans le Web garden. Bien que les
Web gardens n’aient pas d’affinité de session par eux-mêmes,
IIS 6.0 achemine tout le trafic provenant d’une connexion
vers le même processus de travail. Celui-ci stocke l’information
de session, la clé secrète SSL (Secure Sockers Layer) et
l’information d’authentification, jusqu’à  ce que la connexion
soit terminée ou que le processus de travail soit recyclé.
Les Web gardens ne sont pas très utilisés, à  mon avis pour
deux raisons : d’abord parce que la performance et la fiabilité
d’IIS 6.0 sont généralement excellentes sans eux, et aussi
parce que les utilisateurs ne savent pas quel genre d’applications
en tirera parti. J’ai eu du mal à  trouver des exemples
d’installations réelles dans lesquelles cette fonction bonifie
clairement l’application. Si vous en connaissez, veuillez
m’écrire. Cependant, voici quelques exemples.
Un Web garden peut s’avérer utile quand votre application
utilise un composant qui a une restriction intégrée. Par
exemple, si vous avez un objet connexion base de données
qui n’accepte que 10 connexions, vous pouvez valider n processus
de travail pour fournir 10 x n connexions.
Il est un autre scénario plus probable : une connexion
base de données « bloquant » une application. L’application
envoie une requête à  la base de données qui tarde à  répondre.
Le thread (c’est-à -dire, l’unité de travail chargée
d’exécuter le code sur la CPU) qui fait la requête est maintenant
bloqué en attente de cette requête et n’est disponible
pour aucune autre tâche. De ce fait, le pool de threads de travail
disponibles est diminué de 1. Si les requêtes arrivent plus
rapidement que la base de données ne peut les traiter, votre
application peut manquer de threads. Dans un tel scénario,
le Web garden serait utile parce que chaque processus qui s’y
trouve a son propre pool de threads dédié.
A noter qu’ASP.NET a aussi des fonctions Web garden et
affinité de processus qui sont complètement différentes de la
mouture IIS 6.0. Vous trouverez les paramètres de ces fonctions
dans l’élément processModel du fichier machine.config
XML, le fichier de configuration primaire pour des applications
ASP.NET. IIS 6.0 ignore complètement les paramètres
machine.config pour le Web garden et l’affinité de processus
; seul IIS 5.x les utilise. Pour plus d’informations sur
ASP.NET et IIS 6.0, voir « How ASP.NET Works with IIS 6.0 »
(http://www.microsoft.com/technet/treeview/default.asp?url
=/technet/prodtechnol/iss/iis6/proddocs/resguide/iisrg_arc
_dkvi.asp).