IIS 5 et 6 fonctionnent différemment
Lorsqu'une requête arrive, IIS vérifie la carte de script (carte d'extension) et achemine la requête vers aspnet_isapi.dll. Le fonctionnement de cette DLL et la façon dont les requêtes entrent dans le runtime ASP.NET sont différents dans IIS5 et 6. La figure 2 montre un aperçu approximatif de ce processus.
Dans IIS5, aspnet_isapi.dll est hébergé directement dans le processus inetinfo.exe. Si vous définissez le niveau d'isolation du site Web ou du répertoire virtuel sur moyen ou élevé, il sera hébergé dans un processus de travail distinct (isolé) d'IIS. Lorsque la première requête ASP.NET arrive, la DLL (aspnet_isapi.dll) démarrera un autre nouveau processus aspnet_wp.exe et acheminera la requête vers ce processus pour traitement. Ce processus charge et héberge à son tour le runtime .NET. Chaque requête transmise à la DLL ISAPI est acheminée vers ce processus via un appel de canal nommé.
Figure 2 : vue de haut niveau du flux de requêtes depuis IIS vers le runtime ASP.NET et via le pipeline de traitement des requêtes. IIS5 et IIS6 interagissent avec ASP.NET de différentes manières, mais une fois que la requête parvient au pipeline ASP.NET, l'ensemble du flux de traitement est le même.
Contrairement aux versions précédentes du serveur, IIS6 a été entièrement optimisé pour ASP.NET.
IIS6 - Longue vie au pool d'applications
IIS6 apporte des modifications significatives au modèle de traitement IIS n'héberge plus directement le code exécutable externe comme les extensions ISAPI. IIS crée toujours un thread de travail distinct - un pool d'applications - et tout le traitement s'effectue au cours de ce processus, y compris l'exécution des DLL ISAPI. Le pooling d'applications constitue une grande amélioration dans IIS6 car il permet un contrôle très précis sur le code qui sera exécuté dans un thread donné. Les pools d'applications peuvent être configurés sur chaque chemin virtuel ou sur l'ensemble du site Web, vous permettant d'isoler chaque application Web dans son propre processus afin que chaque application soit connectée aux autres applications Web exécutées sur la même machine. Si un processus plante, cela n'affectera pas les autres processus (du moins du point de vue du traitement Web).
De plus, les pools d'applications sont hautement configurables. Vous pouvez configurer l'environnement de sécurité dans lequel les pools s'exécutent en définissant leur niveau d'usurpation d'identité d'exécution, ce qui vous permet de personnaliser les autorisations accordées à une application Web (encore une fois, avec une granularité très fine). Une grande amélioration pour ASP.NET est que le pool d'applications remplace la plupart des paramètres de la section ProcessModel du fichier machine.config. Les paramètres de cette section sont très difficiles à gérer dans IIS5 car ces paramètres sont globaux et ne peuvent pas être remplacés dans le fichier web.config de l'application. Lors de l'exécution d'IIS6, les paramètres liés à ProcessModel sont pour la plupart ignorés et lus à la place à partir du pool d'applications. Notez que la plupart d'entre eux sont mentionnés ici - certains paramètres, tels que la taille du pool de threads et les paramètres du thread IO, sont toujours lus à partir de machine.config, car ils n'ont aucun élément correspondant dans les paramètres du pool de threads.
Les pools d'applications étant des exécutables externes, ces exécutables peuvent être facilement surveillés et gérés. IIS6 fournit une série d'options de vérification de l'état du système, de redémarrage et de délai d'attente, qui peuvent être facilement utilisées pour vérifier et même corriger les problèmes du programme dans de nombreux cas. Enfin, le pool d'applications d'IIS6 ne s'appuie pas sur COM+ comme le mode d'isolation d'IIS5. Cela peut améliorer les performances et améliorer la stabilité (en particulier pour certaines applications internes qui doivent appeler des composants COM).
Bien que les pools d'applications IIS6 soient des EXE distincts, ils le sont. sont hautement optimisés pour les opérations HTTP. Ils communiquent directement avec le pilote HTTP.SYS en mode noyau. Les demandes reçues sont acheminées directement vers le pool d'applications approprié. InetInfo n'est fondamentalement qu'un hyperviseur et un serveur de configuration - la plupart des interactions se produisent directement entre HTTP.SYS et le pool d'applications, ce qui fait d'IIS6 un environnement plus stable et plus efficace que IIS5. Cela est particulièrement vrai pour le contenu statique et les applications ASP.NET.
Un pool d'applications IIS6 possède une compréhension innée d'ASP.NET. ASP.NET peut interagir avec lui au niveau de l'API sous-jacente, ce qui permet d'accéder directement à l'API de mise en cache HTTP. Cela permet de fournir la mise en cache au niveau ASP.NET directement au serveur Web.
Dans IIS6, les extensions ISAPI s'exécutent dans le processus de travail du pool d'applications. Le runtime .NET s'exécute également dans le même processus, de sorte que la communication entre l'extension ISAPI et le runtime .NET se produit au sein du processus. Cela présente un avantage naturel en termes de performances par rapport au canal nommé utilisé par IIS5. Bien que le modèle d'hébergement d'IIS soit très différent, l'interface avec le code managé est étonnamment similaire : seul le processus de routage des messages est légèrement différent.