IIS 7.0
Les 10 principales améliorations en matière de performances dans IIS 7.0
Mike Volodarsky
En un coup d'œil :
- Réduire l'encombrement de votre application
- Réduire les coûts de bande passante
- Utiliser des fonctionnalités de mise en cache améliorées
Sommaire
Des serveurs Web plus légers
Utilisation d'un système d'exploitation léger
Topologies d'applications spécialisées
Prise en charge des applications améliorée
Augmentation de la densité des applications
Réduction de la bande passante à l'aide de la compression
Limitation de la vitesse de transmission multimédia
Mise en cache de sortie
Conversion de Code ISAPI en modules IIS 7.0
Extensibilité de serveur
Conclusion
Durant les réunions que j'organise avec les entreprises qui ont l'intention d'adopter IIS 7.0, une question revient immanquablement : « le passage à IIS 7.0 garantira-t-il des améliorations au niveau des performances des serveurs ou des applications ? » La
réponse est généralement oui, mais ne soyez pas surpris si vous ne voyez pas d'améliorations des performances la première fois que vous migrez vos applications vers IIS 7.0.
Pour comprendre cela, vous devez comprendre la nature de la dernière version. IIS 6.0 était une version technique qui visait un triple objectif : renforcement de la sécurité, augmentation de la fiabilité et amélioration des performances. Par contraste, IIS 7.0 est une version de plate-forme. Son but était de convertir le noyau du serveur Web de base haute qualité de son prédécesseur en une plate-forme modulaire et extensible avec une prise en charge des principaux scénarios de déploiement et de gestion actuels.
Un grand nombre des modifications architecturales et des nouvelles fonctionnalités peuvent en fait avoir un impact négatif sur les performances du serveur Web, dans la mesure où, par exemple, l'une des modifications clés a consisté à diviser des chemins de code de serveur Web solidement optimisés en modules autonomes qui ne font pas l'objet d'un traitement spécial par le serveur Web. Cependant, grâce au solide travail effectué par l'équipe IIS, les performances d'IIS 7.0 sont comparables à celles de son prédécesseur et les dépassent dans certains domaines. De par mon expérience personnelle du noyau du serveur Web et du pipeline intégré, je peux vous affirmer qu'il a fallu beaucoup d'imagination dans la conception et d'efforts dans l'implémentation du produit pour arriver à ce résultat.
Néanmoins, IIS 7.0 est beaucoup plus susceptible de vous offrir des améliorations de performances significatives et de réduire les coûts des performances de votre batterie de serveurs que n'importe quelle autre version précédente d'IIS.
Vous ne verrez pas nécessairement ces avantages en migrant simplement vers IIS 7.0, mais certains environnements ne manqueront pas d'en bénéficier. Par exemple, Microsoft.com a constaté une amélioration de 10 % au niveau de l'efficacité du processeur (vous trouverez l'analyse complète sur le blog de l'équipe Microsoft.com à l'adresse go.microsoft.com/fwlink/?LinkId=122497). Vous risquez également de remarquer des améliorations sensibles dans certains domaines, notamment au niveau de l'authentification SSL (Secure Sockets Layer) et de l'authentification Windows® (toutes deux étant désormais exécutées dans le noyau), et de l'évolutivité verticale sur les ordinateurs multicœurs et multiprocesseurs.
Toutefois, la véritable puissance d'IIS 7.0 ne réside pas dans les améliorations des performances des fonctionnalités existantes mais plutôt dans les nouvelles fonctionnalités que vous devez utiliser activement. Ces fonctionnalités sont souvent enracinées dans la flexibilité et la nature extensible de la plate-forme, ainsi que dans les nouvelles fonctionnalités de performances. Dans cet article, je vous montrerai 10 des sources d'amélioration des performances les plus importantes que vous pourrez déverrouiller en passant à IIS 7.0.
Des serveurs Web plus légers
La possibilité de déployer des serveurs IIS 7.0 légers provient de l'architecture modulaire du serveur. Pratiquement toutes ses fonctionnalités de serveur Web sont implémentées sous forme de composants modulaires qui peuvent être ajoutés ou supprimés individuellement. Vous pouvez ainsi supprimer toute fonctionnalité de serveur qui n'est pas nécessaire au fonctionnement d'une application, ce qui se traduit par des avantages remarquables, notamment une réduction considérable de la surface d'attaque, une réduction de l'encombrement des opérations et des performances améliorées.
Le jeu de fonctionnalités du serveur Web d'IIS 7.0 comprend 44 modules, y compris des modules IIS natifs et des modules ASP.NET qui fournissent des services au pipeline intégré. Ces modules délivrent des services tels que l'authentification (modules d'authentification Windows et d'authentification Digest), la prise en charge de l'infrastructure des applications (module FastCGI), les services d'application (module État de session), la sécurité (module Filtrage des requêtes) et les performances (module Cache de sortie). Néanmoins, un serveur Web minimal qui a simplement besoin de servir du contenu statique peut être fonctionnel avec seulement 2 modules !
Les surcharges dues aux modules inutiles peuvent être assez importantes, par exemple, dans le cas des modules de journalisation des requêtes et de suivi des requêtes en échec. La suppression de tels modules dans les environnements où ils ne sont pas nécessaires peut se traduire par un débit total plus élevé et des réponses plus rapides qui réduisent le temps jusqu'au premier octet (TTFB) et le temps jusqu'au dernier octet (TTLB) pour la charge de travail du serveur.
La figure 1 montre les résultats d'un simple test de débit d'un fichier HTML (charge de travail statique) et d'une page ASP.NET hello world (charge de travail ASP.NET) lorsqu'ils sont configurés avec le jeu de fonctionnalités complet, le jeu de fonctionnalités par défaut de cette charge de travail et le jeu absolument minimal des fonctionnalités nécessaires pour la charge de travail. Bien que la plupart des fonctionnalités non essentielles soient déjà désactivées dans la configuration complète, leur suppression complète de la configuration minimale entraînera une augmentation considérable du débit de la charge de travail statique et de la charge de travail ASP.NET.
Figure 1 Taux de débit de la charge de travail statique et de la charge de travail ASP.NET dans trois configurations différentes avec 100 clients simultanés (Cliquez sur l'image pour l'agrandir)
Par ailleurs, vous verrez peut-être des améliorations au niveau de l'encombrement mémoire et une densité de site plus élevée, surtout dans les environnements d’hébergement partagés ou lorsque plusieurs processus de travail sont utilisés. Ces résultats s'obtiennent généralement en chargeant moins de DLL dans chaque processus et en éliminant toute allocation de mémoire survenant durant l'initialisation de module et le traitement des requêtes. La figure 2 illustre l'utilisation de la mémoire (octets privés du processus de travail IIS) dans le même test de débit. Bien que les améliorations ne soient pas aussi significatives dans cet exemple, les augmentations correspondent aux attentes, puisque la surcharge appdomain ASP.NET est relativement plus élevée que les économies de base offertes par les modules supprimés.
Figure 2 Utilisation de la mémoire (octets privés) des charges de travail statique et ASP.NET dans trois configurations différentes avec 100 clients simultanés (Cliquez sur l'image pour l'agrandir)
IIS 7.0 vous permet également de choisir les modules à activer au niveau de l'application et l'utilisation des modules en fonction de la charge de travail par le biais de préconditions de modules. Cette fonction nécessite, certes, une configuration avancée, mais elle peut offrir d'autres avantages dans les environnements multisites ou dans le cas d'applications qui prennent en charge plusieurs charges de travail distinctes.
Un avertissement, toutefois : il n'est pas toujours facile de déterminer les fonctionnalités dont vous avez besoin. Vous devez considérer non seulement les fonctionnalités minimales nécessaires pour prendre en charge l'infrastructure de votre application mais également toute autre fonctionnalité sur laquelle votre application peut indirectement s'appuyer. Par exemple, votre application peut dépendre de méthodes d'authentification spécifiques ou d'une sémantique d'autorisation fournie par diverses fonctionnalités IIS, auquel cas vous risquez de mettre en péril la sécurité de votre application en les supprimant. De même, votre application peut s'appuyer sur certains modules pour obtenir des effets fonctionnels ou de performances, auquel cas vous risquez des comportements incorrects ou une perte de performances en les supprimant.
Utilisation d'un système d'exploitation léger
Windows Server® 2008 fournit également une répartition en composants du système d'exploitation que vous pouvez utiliser pour réduire davantage la surface d'exposition de votre serveur Web. Server Core est une option d'installation minimale pour le système d'exploitation de Windows Server 2008 et contient un jeu minimal de sous-systèmes de système d'exploitation de base. Server Core est un environnement idéal pour les serveurs Web IIS 7.0 légers.
Toutefois, lorsque vous évaluez Server Core, sachez que certaines restrictions peuvent avoir un impact sur votre application. Server Core ne prend pas en charge Microsoft® .NET Framework, ce qui signifie que vous ne disposerez ni d'ASP.NET, ni de l'extensibilité .NET pour IIS, ni du gestionnaire IIS. En outre, les tâches de gestion locales nécessiteront des outils de ligne de commande puisque il n'y a pas de console MMC (Microsoft Management Console). Du point de vue performances, si vous tirez déjà correctement parti de la répartition en composants IIS, vous ne verrez peut-être pas de différence au niveau de l'encombrement mémoire ou du débit de la charge de travail de votre application exécutée sur Server Core par rapport à une implémentation Windows Server complète. Cela est dû au fait que le travail exécuté par IIS et par votre application est le même sur les deux plates-formes. Cependant, il y a un aspect au niveau duquel vous verrez une différence : l'encombrement général du serveur, en termes d'espace disque et d'utilisation de la mémoire.
En guise d'exemple, la figure 3 montre la différence d'encombrement après l'exécution du test de charge de travail statique sur une configuration Windows Server 2008 complète et sur Server Core. Bien que l'encombrement IIS soit pratiquement identique dans les deux cas, l'encombrement général plus réduit du système d'exploitation de Server Core permet à la charge de travail d'être prise en charge avec beaucoup moins de mémoire. L'encombrement réduit peut en fait vous permettre de déployer la charge de travail de votre application sur un matériel moins puissant en vous concentrant sur les demandes de traitement de l'application et non sur l'environnement d'exploitation. Bien sûr, cela fait de Server Core une excellente option pour les environnements virtualisés.
Figure 3 Encombrement mémoire d'un Windows Server 2008 complet par rapport à Server Core après l'exécution du test de charge de travail statique (Cliquez sur l'image pour l'agrandir)
Topologies d'applications spécialisées
Durant le travail d'optimisation, vous pouvez diviser les charges de travail de votre application en plusieurs parties distinctes. Par exemple, au lieu d'exécuter votre application sur une batterie de 30 serveurs Web identiques, vous pouvez l'exécuter sur 10 serveurs Web, 5 serveurs d'application et 3 serveurs proxy qui exécutent la mise en cache et la compression.
Cette spécialisation fonctionne bien pour plusieurs raisons. Tout d'abord, les performances de nombreuses charges de travail d'application sont étroitement liées à toute une série de ressources partagées, telles que la mémoire, qui pourraient être sollicitées par différentes parties de l'application. La concurrence pour ces ressources peut créer des goulots d'étranglement qui empêchent chaque serveur d'être pleinement utilisé à travers d'autres ressources. Si vous séparez des parties de l'application, vous leur donnez accès aux ressources qui seraient autrement contestées, ce qui entraîne de meilleures performances sur le même ensemble de ressources matérielles.
Ensuite, la spécialisation peut permettre à l'application d'atteindre une plus grande localité de cache, améliorant ainsi les performances. Ceci inclut les caches de bas niveau tels que le tampon de traduction TLB (Translation Lookaside Buffer) de la mémoire virtuelle, le cache du système de fichiers et d'autres caches du système d'exploitation et des applications. Une autre source de gain de localité est le processeur. En réduisant le nombre d'activités parallèles qui se produisent en se concentrant seulement sur une partie spécifique de l'application, l'application peut réduire le nombre de commutateurs de contexte et optimiser le travail effectué par le processeur.
Par ailleurs, la spécialisation permet également une optimisation spécifique à la charge de travail, ce qui améliore le fonctionnement de chaque partie de l'application. Un grand nombre de ces optimisations ne sont pas possibles lorsque l'application toute entière est prise en charge sur le même serveur en raison des besoins contradictoires de différentes parties de l'application.
C'est souvent le cas de la configuration des threads IIS et ASP.NET qui a un effet considérable sur la simultanéité et affecte indirectement l'utilisation de la mémoire, la latence et le débit de beaucoup d'applications. La charge de travail de fichier statique IIS est extrêmement asynchrone et nécessite une haute limite des requêtes simultanées, mais est extrêmement à l'aise lorsque le nombre de threads disponibles est très bas. D'autre part, de nombreuses fonctionnalités d'ASP.NET sont synchrones, ont un blocage long et nécessitent un nombre de threads élevé, tandis que d'autres nécessitent une limite de simultanéité plus basse pour réduire l'impact sur la mémoire. En séparant la charge de travail statique et en décomposant des parties du pipeline de traitement des requêtes dans un processus ou un serveur séparé, vous pouvez optimiser la simultanéité de chaque charge de travail individuelle.
Enfin, la spécialisation peut conduire à une meilleure évolutivité d'ensemble en permettant à l'application d'effectuer une évolution horizontale de charges de travail ou de parties discrètes de l'application indépendamment les unes des autres. Ceci peut permettre à la topologie de l'application d'atteindre une capacité et une redondance accrues là où elles sont le plus nécessaires, et vous évite donc d'avoir à appliquer le même modèle à l'application toute entière. Dans ce modèle, les ressources spécialisées peuvent être des serveurs physiques, des serveurs virtuels ou même des pools d'applications sur la même machine.
Lorsque vous évaluez les avantages potentiels de la spécialisation dans la topologie de votre application, commencez par localiser les goulots d'étranglement exigeant beaucoup de traitement ou de ressources dans votre application. Ces zones devraient être les premières à être concernées par la spécialisation car elles peuvent s'avérer une importante source d'optimisation lorsqu'elles sont isolées, et parce qu'elles exigeront une évolution horizontale de niveau supérieur. Ensuite, déterminez si le fait de les isoler permettra au reste de l'application d'utiliser les ressources de manière plus efficace. Enfin, vous devrez évaluer la surcharge du mécanisme de connectivité nécessaire pour rassembler les composants isolés de l'application.
Prise en charge des applications améliorée
IIS 7.0 comprend une prise en charge étendue des infrastructures d'application par le biais de FastCGI, un protocole ouvert pris en charge par de nombreuses infrastructures d'application Open Source qui autrement ne pourraient peut-être pas supporter une intégration native hautes performances à IIS. Contrairement au protocole CGI (Common Gateway Interface) qui est pris en charge par IIS depuis longtemps, FastCGI offre de bien meilleures performances sur la plate-forme Windows. Ceci est principalement dû à l'architecture à processus réutilisables de FastCGI, qui élimine la lourde surcharge de la création de processus à la demande, permettant ainsi aux clients d'utiliser des connexions persistantes toujours actives.
Si vous prenez en charge des infrastructures d'application sur ILS à l'aide du protocole CGI ou d'un autre mécanisme, vous pourriez obtenir de meilleures performances (et dans certains cas, une meilleure stabilité) en passant au protocole FastCGI.
La première infrastructure d'application à tirer parti de cette prise en charge est PHP. En fait, l'équipe IIS a collaboré directement avec Zend Technologies pour s'assurer que l'implémentation d'IIS FastCGI fonctionne correctement avec PHP et permet d'améliorer les performances de l'infrastructure PHP sur Windows. (Pour plus d'informations sur le projet, consultez l'entrée sur mon blog à l'adresse go.microsoft.com/fwlink/?LinkId=122509.) Si vous avez un mélange de technologies de serveur Web qui incluent des applications ASP ou ASP.NET s'exécutant sur IIS et PHP ou d'autres infrastructures d'application compatibles FastCGI utilisant d'autres technologies, vous pourrez probablement consolider ces applications sur la plate-forme IIS 7.0.
En migrant PHP et autres infrastructures d'application vers IIS 7.0 et FastCGI, vous pourrez tirer avantage de plusieurs fonctionnalités d'IIS 7.0, dont le pipeline ASP.NET intégré. Il est ainsi possible d'améliorer les infrastructures d'application avec des services ASP.NET sans les convertir à ASP.NET. Ceci permet également à des applications utilisant des infrastructures différentes de collaborer. Pour voir comment ajouter des fonctionnalités aux applications existantes et en améliorer les performances sans aucune modification de code, consultez mon article de MSDN® Magazine intitulé « Améliorez vos applications grâce au pipeline ASP.NET intégré » (disponible à l'adresse msdn.microsoft.com/magazine/cc135973.aspx).
Augmentation de la densité des applications
IIS 7.0 inclut de nombreuses améliorations destinées à augmenter la densité des applications qui peuvent être hébergées sur un seul serveur. Ces améliorations font partie des nombreuses fonctionnalités qu'IIS 7.0 propose pour améliorer la qualité des hébergements partagés, notamment par une meilleure mise en service des sites et un meilleur isolement des applications.
Du point de vue des performances, les améliorations portent principalement sur deux aspects liés à l'augmentation de la densité des applications : l'augmentation du nombre d'applications qui peuvent être configurées sur un serveur IIS 7.0 et l'augmentation du nombre d'applications qui peuvent être actives à tout moment.
Notez qu'IIS 7.0 facilite la mise en service d'un plus grand nombre d'applications sur chaque serveur ; lors de certains tests internes, ce nombre a atteint 100 000 sites sur un seul serveur. Ceci exploite la possibilité de créer et de configurer plusieurs sites et applications.
Un avertissement, toutefois : pour obtenir une mise en service rapide, vous devez passer aux nouvelles API de configuration, les anciennes n'en étant pas capables. En outre, les API de configuration IIS ne fournissent pas toutes les mêmes caractéristiques de performances ; choisissez donc avec soin pour garantir des performances de haute qualité. Dans le doute, choisissez des options de configuration qui s'appuient directement sur les nouveaux objets de configuration IIS, notamment l'espace de noms Microsoft.Web.Administration, l'outil de ligne de commande AppCmd.exe et les objets de configuration COM d'IIS accessibles depuis le script, .NET ou le code C++.
La différence entre le nombre de sites qui peuvent être configurés et le nombre de sites qui peuvent être actifs est une distinction très importante dans l'architecture IIS, qui utilise des applications et processus de travail persistants pour exécuter le traitement des requêtes. Dans ce modèle, les applications actives consomment plus de ressources sur le serveur mais offrent également de meilleures performances soutenues grâce à la mise en cache et à la suppression des coûts d'initialisation.
Étant donné que chaque application active nécessite une certaine quantité de mémoire et un processus de travail séparé (si le modèle d'isolement d'application recommandé est utilisé), le nombre d'applications actives est étroitement lié à l'encombrement mémoire de l'application. Ainsi, si une application unique servant seulement du contenu statique peut ne nécessiter que 3 Mo pour son processus de travail (et peut même partager le même processus de travail avec d'autres applications de contenu statique), certaines applications dynamiques peuvent nécessiter 100 Mo de RAM ou plus même lorsqu'elles sont peu utilisées. Ceci rend insignifiante la surcharge de mémoire du processus de travail IIS lui-même par rapport à l'encombrement de l'application lors de la définition de la densité maximale possible.
Dans le scénario d'hébergement partagé typique, il est courant de voir ce que l'on appelle une distribution 80/20 dans laquelle 80 % de requêtes vont à 20 % de sites. Cette distribution se traduit par un nombre réduit de sites actifs à tout moment. Pour permettre un nombre de sites plus élevé, IIS 7.0 propose une gestion de la durée de vie active. Ceci peut vous aider à récupérer de la mémoire des applications inactives afin de permettre à davantage d'applications actives d'être hébergées.
IIS 7.0 introduit un nouvel algorithme appelé durée d'inactivité dynamique, qui ajuste de façon proactive les délais d'inactivité des processus de travail en fonction de la mémoire disponible sur le serveur. À mesure que le niveau de la mémoire diminue, les applications inactives sont supprimées plus rapidement, ce qui permet d'héberger davantage d'applications actives. Cependant, si la mémoire est disponible, les délais d'inactivité peuvent rester grands afin d'assurer de meilleures performances et de maintenir l'état des applications. En plus de permettre à davantage d'applications d'être actives, la durée d'inactivité dynamique contribue également à éviter les conditions de mémoire basse qui causent une sérieuse dégradation des performances en raison de conflits.
Pour rendre possible l'hébergement d'un grand nombre d'applications actives, vous devriez également utiliser un système d'exploitation 64 bits car cela permettra au système d'exploitation de traiter plus de 4 Go de mémoire. En outre, vous pouvez configurer les processus de travail IIS de sorte qu'ils s'exécutent en mode 32 bits (SysWoW64), mode dans lequel ils utilisent eux-mêmes moins de mémoire tout en permettant au système d'exploitation de traiter plus de mémoire qu'il n'est possible dans un environnement 32 bits.
Réduction de la bande passante à l'aide de la compression
Il n'est pas surprenant que les coûts associés à la bande passante soient parmi les coûts les plus importants lorsqu'il s'agit de gérer un centre de données accessible par Internet. En outre, la bande passante requise pour fournir le contenu demandé est un facteur clé dans la réactivité perçue de votre application.
L'un des meilleurs moyens de réduire la bande passante nécessaire pour produire les réponses d'application est d'utiliser la compression HTTP. Cette compression peut permettre une réduction considérable de la taille de la réponse, souvent par un facteur de 10, lorsqu'elle est appliquée à un contenu de texte aisément compressible tel que le HTML. Par ailleurs, pratiquement tous les navigateurs de bureau la prennent en charge, et les coûts de décompression sur le matériel de bureau sont mineurs comparés aux économies de latence générée par l'envoi de moins de données. Et puisque la compression est fondée sur la négociation Contenu-Codage définie dans le protocole HTTP 1.1, son activation ne pose aucun problème aux clients qui ne la prennent pas en charge ; ces clients reçoivent tout simplement une version sans compression du contenu.
IIS 7.0 fournit les deux fonctionnalités de compression introduites par son prédécesseur : la compression statique et la compression dynamique. La compression statique compresse à l'avance le contenu statique et l'enregistre sur disque, permettant ainsi aux futures requêtes de servir du contenu compressé directement, sans surcharge de compression. La compression dynamique compresse la réponse en temps réel, ce qui permet une compression des réponses générées par les applications. N'importe quelle infrastructure d'application d'IIS 7.0 peut bénéficier de la compression dynamique, y compris ASP, ASP.NET ou PHP.
En dépit d'un mythe courant, la compression dynamique n'a généralement pas une trop grande surcharge de processeur. En fait, la compression dynamique génère souvent moins de 5 % de l'utilisation totale du processeur sur un serveur très sollicité. La compression dynamique peut être déployée de manière quelque peu libérale pour permettre des économies de bande passante maximales pour n'importe quelles charges de travail d'application.
Vous pouvez optimiser davantage la surcharge de compression en configurant la force de compression au niveau désiré par rapport au taux de surcharge du processeur. Enfin, vous pouvez également configurer votre application de sorte à activer la mise en cache du contenu compressé, ce qui élimine la surcharge de compression lors de l'accès au cache en servant du contenu déjà compressé. Notez que les caches de sortie ASP.NET et IIS ont tous deux été mis à niveau avec possibilité (facultative) de mettre en cache le contenu compressé pour les clients qui le prennent en charge, et de traiter les requêtes des clients nécessitant du contenu non compressé.
Limitation de la vitesse de transmission multimédia
Avec le nombre croissant de sites proposant du contenu multimédia, les coûts associés à la bande passante montent en flèche pour beaucoup d'entreprises. Pire encore, un grand pourcentage de bande passante multimédia est gaspillé parce que le contenu multimédia envoyé au client n'est jamais vraiment utilisé. À quoi cela est-il dû ?
Souvenez-vous de la dernière fois que vous avez regardé une vidéo en ligne ou vu une publicité vidéo en navigant sur Internet. Avez-vous regardé la vidéo jusqu'à la fin ? Souvent, les utilisateurs parcourant des sites vidéo ne regardent qu'une partie d'une vidéo avant de passer à la vidéo ou à la page suivante. Cependant, un serveur Web utilisant le téléchargement progressif pour fournir la vidéo enverra généralement beaucoup plus de données qu'il n'en est nécessaire pour ces quelques secondes de lecture. La plupart de ces données ne sont jamais utilisées.
Si vos vidéos n'utilisent en moyenne que 5 secondes de temps de lecture mais mettent en tampon des données représentant 30 secondes de lecture, cela signifie que vous gaspillez plus de 80 % de votre bande passante !
Il y a un an, pour résoudre ce problème pour un client adoptant une version bêta d'IIS 7.0, j'ai écrit un module de limitation de la bande passante qui détectait automatiquement la vitesse de transmission vidéo et faisait en sorte que le serveur délivre la vidéo au client plus ou moins à la même vitesse. L'équipe multimédia d'IIS a aimé ce module, appelé Module de limitation de la vitesse de transmission (voir figure 4), et il est désormais disponible dans le centre de téléchargement iis.net (iis.net/downloads/?tabid=34&g=6&i=1640). Vous en apprendrez plus à son sujet sur le blog de Scott Guthrie (disponible à go.microsoft.com/fwlink/?LinkId=122514).
Figure 4 La limitation de la vitesse de transmission réduit l'utilisation de la bande passante (Cliquez sur l'image pour l'agrandir)
Le module de limitation de la vitesse de transmission détecte automatiquement la vitesse d'encodage des types de vidéo les plus courants. Vous pouvez contrôler la quantité de données à envoyer au client afin d'éliminer les retards de mise en tampon initiaux (démarrage rapide) et le pourcentage de la vitesse encodée auquel vous aimeriez livrer le contenu. Vous pouvez également configurer de nombreuses autres options telles que la bande passante maximale et les connexions simultanées, et contrôler le module par programmation.
Mise en cache de sortie
En général, la mise en cache est la méthode la plus utilisée pour améliorer les performances des applications qui effectuent un travail continu. Contrairement aux améliorations des performances spécifiques à une application qui nécessitent souvent beaucoup d'efforts et entament lentement la surcharge de traitement d'une application, la mise en cache élimine la surcharge des requêtes répétées pour le même contenu.
Avant IIS 7.0, IIS et ASP.NET proposaient tous deux des fonctionnalités de mise en cache sous la forme du cache de noyau IIS et du cache de sortie ASP.NET. Le cache de noyau IIS offrait des performances maximales mais était essentiellement limité au contenu statique. Le cache de sortie ASP.NET était une solution beaucoup plus complète pour la mise en cache de contenu dynamique, avec, toutefois, des performances plus lentes et une gestion de la mémoire moins efficace. Le nouveau cache de sortie d'IIS 7.0 réduit l'écart entre le cache de noyau IIS et le cache de sortie ASP.NET.
Le cache de sortie IIS 7.0 permet de mettre en cache le contenu dynamique de n'importe quelle application, y compris ASP, ASP.NET, PHP et toute autre infrastructure d'application compatible IIS 7.0. En proposant une prise en charge de base de la variabilité et de l'expiration du contenu, cette nouvelle fonctionnalité facilite l'implémentation de la mise en cache de contenu qui ne peut pas être mis en cache par le cache de noyau IIS. Elle permet néanmoins d'utiliser le cache de noyau pour un contenu qui est sujet à des restrictions.
En outre, le cache de sortie IIS 7.0 propose une alternative offrant des performances supérieures au cache de sortie ASP.NET pour le contenu ASP.NET qui ne nécessite pas les fonctionnalités de mise en cache avancées (telles que les dépendances ou l’invalidation de cache) qui ne sont disponibles que dans le cache de sortie ASP.NET.
Les problèmes liés à la mise en cache de sortie résident normalement dans la définition des stratégies d'expiration, d'invalidation et de variabilité de contenu appropriées qui permettent une mise en cache des réponses efficace tout en maintenant l'exactitude et l'actualité du cache. Pour ce faire, il suffit souvent de bien configurer les règles de mise en cache, bien que certaines situations nécessitent des stratégies plus complexes qui dépendent des informations sur le runtime. C'est à cet effet que le cache de sortie IIS 7.0 propose des API de programmation qui peuvent être utilisées pour garantir le comportement de mise en cache requis. Ceci permet de déverrouiller le potentiel des performances de la mise en cache de contenu qui ne pourrait pas autrement être mis en cache. En outre, le pipeline ASP.NET intégré permet l'utilisation du cache de sortie ASP.NET pour un contenu non ASP.NET.
Le déploiement de la mise en cache de sortie pour le contenu dynamique peut être difficile et peut nécessiter une stratégie multiniveau pour exploiter l'efficacité et la flexibilité des différentes fonctionnalités de mise en cache sur la plate-forme IIS 7.0. Ainsi, il est souvent nécessaire de décrire plusieurs paramètres qui affectent la réponse et de définir des stratégies d'expiration et d'invalidation pour maintenir l'actualité du cache, puis de déterminer le cache qui prendra en charge la sémantique requise.
Toutefois, cette complexité en vaut très souvent la chandelle. En implémentant le cache de sortie IIS 7.0, vous pouvez obtenir des améliorations considérables du débit général de votre application et une réduction de même importance de la charge sur votre base de données et vos composants métier.
Conversion de Code ISAPI en modules IIS 7.0
IIS 7.0 introduit une nouvelle API de serveur sur laquelle sont basés tous les modules d'IIS 7.0. Elle remplace le filtre ISAPI et les API de l'extension ISAPI utilisés dans les versions précédentes d'IIS. Pour les nouveaux modules qui n'ont pas besoin de prendre en charge les versions précédentes, les nouvelles API sont plus faciles à utiliser, aident à produire du code côté serveur plus fiable et sont beaucoup plus puissantes.
Cependant, IIS 7.0 offre une option de prise en charge des filtres et extensions ISAPI existants grâce à une couche de compatibilité implémentée par le biais de modules IIS 7.0 facultatifs. Ceci permet aux composants ISAPI existants de fonctionner sur IIS 7.0 sans nécessiter de réécriture.
Bien que l'utilisation d'investissements ISAPI existants réduise le coût de la migration vers IIS 7.0, vous devriez sérieusement envisager la migration du code ISAPI hérité vers les nouvelles API d'IIS 7.0. Vous éliminez ainsi les surcharges de la couche de compatibilité ISAPI et déverrouillez des avantages de performances qui ne sont pas disponibles pour les composants ISAPI. Selon le travail effectué par le composant ISAPI, ces avantages de performances peuvent être très importants. Par exemple, l'API de module d'IIS 7.0 fournit une prise en charge intégrée de la mise en cache des métadonnées de configuration et autres données arbitraires associées aux sites, aux applications et aux URL, ce qui peut améliorer considérablement la vitesse des opérations internes du composant.
En outre, l'API de module d'IIS permet aux modules d'exécuter des opérations de longue durée (réception de données d'entité de requête ou envoi de réponse, par exemple) de manière asynchrone. L'exécution asynchrone de ces tâches permet au serveur de traiter un très grand nombre de clients simultanés (des dizaines de milliers) au lieu de quelques dizaines ou, au maximum, de quelques centaines de clients simultanés, en raison des limites liées au nombre de threads de requêtes. Le traitement asynchrone peut également éliminer l'effet du traitement sur les autres requêtes et activités dans l'application, réduire l'utilisation de la mémoire et permettre une bien meilleure utilisation du processeur.
En plus des modèles spécifiques affectant les performances, l'API native donne aux développeurs une plus grande flexibilité dans les tâches de traitement des requêtes. Ceci vous permet d'améliorer la conception du composant serveur, et par là même d'atteindre d'autres performances positives. Par exemple, certaines tâches de filtrage qui nécessitaient auparavant des extensions ISAPI génériques et l'exécution de requête enfant peuvent désormais être exécutées dans un module durant la requête originale, et peuvent également permettre une mise en cache de la réponse dans le noyau IIS.
Ceci peut nécessiter un certain prototypage et une certaine expérimentation afin de déterminer la conception qui optimise les avantages de la migration. En raison des différences d'architecture fondamentales entre ISAPI et l'API de module d'IIS 7.0, la voie du portage direct n'est pas nécessairement la bonne. La bonne nouvelle, c'est que l'API de module d'IIS 7.0 est également plus simple à utiliser que l'ISAPI, ce qui rend la migration moins difficile.
Extensibilité de serveur
IIS 7.0 offre une extensibilité de bout en bout. Il nécessite des connaissances préalables du fonctionnement des serveurs, mais il libère également un énorme potentiel de gains de performances spécifiques aux applications. Grâce à vos connaissances en matière d'architecture de serveur et de traitement des requêtes, vous pouvez tirer parti de cette extensibilité pour concevoir des solutions de performances personnalisées, adaptées à votre application, votre charge de travail et votre matériel.
Vous pouvez le faire en remplaçant notamment toutes les fonctionnalités intégrées à IIS 7.0 par des implémentations personnalisées. Bien que les fonctionnalités d'IIS 7.0 aient subi de nombreux tests d'optimisation et de performances, elles n'ont, bien sûr, pas été optimisées pour chaque utilisation possible. Ainsi, vous pouvez être à même d'améliorer les performances de modules spécifiques en intégrant des optimisations pour votre charge de travail spécifique. Par exemple, vous pouvez décider de réimplémenter le module de liste de répertoires pour mettre en cache les listes dans la mémoire au lieu d'utiliser les API de système de fichiers pour énumérer les fichiers.
Vous pouvez également utiliser l'extensibilité pour créer de nouvelles fonctionnalités de performances. Les exemples prédéfinis de telles fonctionnalités incluent le cache de sortie, les modules de compression et plusieurs autres caches internes.
Pour déterminer la nécessité d'une fonctionnalité de performances personnalisée, vous devez comprendre les caractéristiques de performances de votre application et sa charge de travail, et connaître le goulot d'étranglement que vous devrez traiter. IIS 7.0 offre une large prise en charge de diagnostic pour l'analyse des performances, ce qui peut rendre plus claires les exigences et la conception des fonctionnalités dont vous avez besoin.
Conclusion
Bien que la version IIS 7.0 soit principalement une version fonctionnelle, elle propose des améliorations de performances remarquables qui dérivent de son architecture modulaire, de sa configurabilité et de ses nouvelles fonctionnalités de performances. Ces améliorations peuvent ouvrir la voie à des économies considérables grâce à la consolidation des serveurs et à la réduction des coûts de bande passante, tout en offrant une meilleure expérience utilisateur.
Pour tirer le meilleur parti d'un grand nombre de ces améliorations, il est souvent nécessaire d'effectuer une analyse détaillée de votre plate-forme d'application actuelle et de bien connaître l'architecture d'IIS 7.0. Pour en savoir plus sur l'architecture d'IIS 7.0 et les fonctionnalités mentionnées dans cet article, consultez iis.net. Sur mvolo.com, je proposerai d'autres discussions sur les techniques qui s'appuient de façon proactive sur IIS 7.0 pour améliorer les performances des applications et réduire les coûts d'exploitation.
Mike Volodarsky est un ancien responsable de programme au sein de l'équipe IIS de Microsoft. Durant les cinq dernières années, il a supervisé la conception et le développement de fonctionnalités de base pour ASP.NET 2.0 et IIS 7.0. Actuellement, il crée des technologies de serveur Web avancées pour les batteries de serveurs Web hautes performances qui utilisent IIS 7.0 et Windows Server 2008. Mike est l'auteur principal du livre IIS 7.0 Resource Kit et écrit énormément pour MSDN Magazine et son blog IIS 7.0, mvolo.com.