Fonctionnalité

Description

HTTP.sys : nouveau pilote en mode noyau

Le nouveau pilote en mode noyau, HTTP.sys, constitue un point de contact unique pour toutes les requêtes HTTP entrantes (côté serveur). Cela se traduit par une connectivité élevée pour les applications serveur HTTP. Ce pilote réside au-dessus de TCP/IP et reçoit toutes les demandes de connexion émanant des combinaisons IP/port qu'il est configuré pour écouter. HTTP.sys est également chargé de la gestion globale des connexions, de la gestion de la bande passante et de la journalisation des événements de serveur Web. Des tests préliminaires indiquent des gains de performance de 200 % en débit du contenu statique, et les réponses mises en cache bénéficient d’un débit 165 % supérieur à celui d’IIS 5.0.

Stratégie de mise en cache et gestion des threads

IIS 6.0 possède une excellent algorithme intégré lui permettant de déterminer les éléments essentiels d’une application ou d’un ensemble de sites pouvant être mis en cache. Il n'est pas toujours intéressant d'ajouter un élément à un cache en mémoire simplement parce qu’il peut être mis en cache car la gestion de cet élément a un coût, ainsi que la mémoire qu’il consomme. C’est pour cette raison qu’IIS 6.0 utilise un nouvel algorithme pour identifier les éléments à mettre en cache en fonction de la distribution des requêtes que reçoit une application particulière. Cela signifie que le serveur Web fait un meilleur usage de ses ressources tout en offrant le même niveau de performance sur les requêtes fréquentes, autrement dit son évolutivité est améliorée.

IIS 6.0 possède également une heuristique intégrée pour surveiller l’état général du serveur prendre  des décisions opportunes pour augmenter/réduire le nombre d'accès simultanés en conséquence. L’important dans ce cas est d'utiliser l'accès simultané de façon efficace. Par exemple, lors de l’exécution de requêtes liées au processeur, le démarrage d’un travail concurrent ne constitue pas toujours la meilleure approche.

Web Gardens

Un Web garden est un pool d’applications doté de plusieurs processus traitant les requêtes envoyées à ce pool. Vous pouvez configurer les processus de travail d’un Web garden en vue de les associer à un certain groupe de processeurs sur un système multiprocesseurs. Grâce aux Web gardens, les applications Web bénéficient d’une meilleure évolutivité parce qu’un verrouillage logiciel d’un processus ne bloque pas toutes les requêtes envoyées à une application. S’il y a 4 processus dans un jardin Web, un verrouillage logiciel spécifique bloque à peu près un quart des requêtes.

Cache de modèles ASP persistant

Avant que le code ASP soit exécuté dans IIS 5.0, le moteur ASP compile un fichier ASP en un modèle ASP. Ces modèles ASP sont stockés dans la mémoire des processus. Si un site comporte de nombreuses pages ASP, ce cache annule l’affectation des anciens modèles dans la mémoire afin de libérer de la place pour les nouveaux. Avec IIS 6.0, ces modèles persistent sur le disque. Si un de ces fichiers ASP fait à nouveau l’objet d’une requête, le moteur ASP charge le modèle à la place du fichier ASP, ce qui lui évite de surcharger le processeur avec une nouvelle compilation. Les tests préliminaires montrent des gains de performance au niveau du débit pouvant dépasser 50 % avec IIS 6.0 et ASP grâce à un cache persistant sur le disque.

Prise en charge d’une grande capacité de mémoire pour les systèmes x86

Pour une charge de travail nécessitant de grandes quantités de données mises en cache, IIS 6.0 peut être configuré pour utiliser un cache allant jusqu’à 64 Go sur un système x86.

Fonctionnalité

Description

Intégration d'ASP.NET et d'IIS, et vaste choix de langages

Windows Server 2003 offre une expérience de développement plus intense grâce à l’intégration d'ASP.NET et d'IIS. Reposant sur IIS 6.0, les innovations de la plate-forme offrent aux développeurs des atouts considérables : la rapidité de développement des applications et un large choix de langages. Avec Windows Server 2003, l’expérience d’ASP.NET et du .NET Framework est améliorée du fait d’une meilleure intégration des modèles de processus. IIS 6.0 prend en charge les normes Web les plus récentes, notamment XML, SOAP et IPv6.

ExecuteURL

ExecuteURL offre la fonctionnalité nécessaire pour remplacer presque tous les filtres de lecture de données brutes (« raw data »). Dans le scénario le plus courant de développement de filtres de lecture de données brutes, les utilisateurs souhaitent examiner ou modifier le corps de l’entité de requête avant que l’URL de destination ne le traite. Actuellement, les notifications de lecture des données brutes constituent le seul moyen de voir le corps de l’entité d’une requête (si vous n’êtes pas l’URL de destination). Malheureusement, l’écriture d’un filtre ISAPI à cet effet peut s’avérer particulièrement complexe, voire impossible dans certaines configurations. En revanche, les extensions ISAPI offrent la fonctionnalité nécessaire à la récupération simple et à la manipulation du corps de l’entité. ExecuteURL permet à une extension ISAPI de traiter le corps de l’entité de requête et de le passer à une requête enfant, ce qui répond aux besoins de presque tous les développeurs de filtres de lecture de données brutes.

Intercepteurs globaux

Grâce à ExecuteURL, IIS 6.0 peut mettre en œuvre des intercepteurs de requêtes ISAPI capables d’intercepter, de modifier, de rediriger ou de refuser toute requête HTTP entrante pour un espace URL spécifique. IIS 5.0 prend déjà en charge une extension ISAPI interceptant toutes les requêtes avec un seul script à caractère générique (*), configuré via la modification des mappages d’une application. Dans IIS 6.0, ce concept est étendu et permet d’exécuter simultanément plusieurs intercepteurs globaux.

VectorSend

Implémenté en tant de fonction de prise en charge serveur pour des ISAPI, VectorSend permet aux développeurs de rassembler dans une liste tous les tampons et descripteurs de fichiers à envoyer, dans l’ordre, puis de la transmettre à IIS 6.0 pour qu’il compile la réponse finale. HTTP.sys compile tous les tampons et/ou descripteurs de fichiers en un tampon de réponse unique au sein du noyau, puis il l’envoie. De cette façon, ISAPI n’a plus à s’occuper de la création des tampons ni d’écritures multiples pour les clients.