Optimisation de IIS 10.0
Internet Information Services (IIS) 10.0 est inclus dans Windows Server 2022. Il utilise un modèle de processus similaire à celui d’IIS 8.5 et d’IIS 7.0. Un pilote web en mode noyau (http.sys) reçoit et route les requêtes HTTP, et répond aux requêtes à partir de son cache de réponses. Les processus de travail s’inscrivent pour les sous-espaces d’URL et http.sys route la requête vers le processus approprié (ou l’ensemble de processus pour les pools d’applications).
HTTP.sys est responsable de la gestion des connexions et de la gestion des requêtes. La requête peut être traitée à partir du cache HTTP.sys ou passée à un processus de travail pour qu’il la traite. Plusieurs processus de travail peuvent être configurés, ce qui fournit une isolation à un coût réduit. Pour plus d’informations sur le fonctionnement de la gestion des requêtes, consultez la figure suivante :
HTTP.sys inclut un cache de réponses. Quand une requête correspond à une entrée dans le cache de réponses, HTTP.sys envoie la réponse du cache directement à partir du mode noyau. Certaines plateformes d’applications web, comme ASP.NET, fournissent des mécanismes permettant de mettre en cache n’importe quel contenu dynamique dans le cache en mode noyau. Le gestionnaire de fichiers statiques dans IIS 10.0 met automatiquement en cache les fichiers fréquemment demandés dans http.sys.
Comme un serveur web a des composants en mode noyau et en mode utilisateur, les deux composants doivent être optimisés pour obtenir les meilleures performances. Par conséquent, l’optimisation d’IIS 10.0 pour une charge de travail spécifique inclut la configuration des éléments suivants :
HTTP.sys et le cache en mode noyau associé
Les processus de travail et IIS en mode utilisateur, y compris la configuration du pool d’applications
Certains paramètres d’optimisation qui affectent les performances
Les sections suivantes expliquent comment configurer les aspects du mode noyau et du mode utilisateur d’IIS 10.0.
Paramètres du mode noyau
Les paramètres de HTTP.sys liés aux performances se répartissent en deux grandes catégories : la gestion du cache, et la gestion des connexions et des requêtes. Tous les paramètres du Registre sont stockés sous l’entrée de Registre suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters
Remarque Si le service HTTP est déjà en cours d’exécution, vous devez le redémarrer pour que les modifications prennent effet.
Paramètres de gestion du cache
Un avantage de HTTP.sys est qu’il fournit un cache en mode noyau. Si la réponse se trouve dans le cache en mode noyau, vous pouvez satisfaire une requête HTTP entièrement à partir du mode noyau, ce qui réduit considérablement le coût en processeur de la gestion de la requête. Cependant, le cache en mode noyau d’IIS 10.0 est basé sur la mémoire physique, et le coût d’une entrée est la mémoire qu’elle occupe.
Une entrée dans le cache n’a de valeur que quand elle est utilisée. Cependant, l’entrée consomme toujours de la mémoire physique, que l’entrée soit ou non utilisée. Vous devez évaluer l’utilité d’un élément dans le cache (les économies liées à la possibilité de le délivrer à partir du cache) et son coût (la mémoire physique occupée) sur la durée de vie de l’entrée, en tenant compte des ressources disponibles (processeur et mémoire physique) et des exigences des charges de travail. HTTP.sys tente de conserver seulement les éléments utiles et qui font l’objet d’accès effectifs dans le cache, mais vous pouvez augmenter les performances du serveur web en optimisant le cache HTTP.sys pour des charges de travail particulières.
Voici quelques paramètres utiles pour le cache HTTP.sys en mode noyau :
UriEnableCache Valeur par défaut : 1
Une valeur différente de zéro active la réponse en mode noyau et la mise en cache des fragments. Pour la plupart des charges de travail, le cache doit rester activé. Envisagez de désactiver le cache si vous vous attendez à un niveau de réponse et de mise en cache de fragments très bas.
UriMaxCacheMegabyteCount Valeur par défaut : 0
Une valeur différente de zéro qui spécifie la mémoire maximale disponible pour le cache en mode noyau. La valeur par défaut, 0, permet au système d’ajuster automatiquement la quantité de mémoire disponible pour le cache.
Remarque La spécification de la taille définit seulement la valeur maximale, et le système peut ne pas laisser le cache atteindre la taille maximale définie.
Â
UriMaxUriBytes Valeur par défaut : 262 144 octets (256 Ko)
La taille maximale d’une entrée dans le cache en mode noyau. Les réponses ou les fragments d’une taille supérieure ne sont pas mis en cache. Si vous avez suffisamment de mémoire, envisagez d’augmenter la limite. Si la mémoire est limitée et que les entrées de grande taille supplantent les entrées plus petites, il peut être utile de réduire la limite.
UriScavengerPeriod Valeur par défaut : 120 secondes
Le cache HTTP.sys est analysé régulièrement par un nettoyeur, et les entrées qui ne font pas l’objet d’accès entre ses analyses sont supprimées. Définir une période de nettoyage sur une valeur élevée réduit le nombre d’analyses par le nettoyeur. Cependant, l’utilisation de la mémoire du cache peut augmenter, car les entrées plus anciennes et qui font l’objet d’accès moins fréquents peuvent rester dans le cache. Définir une période trop courte entraîne des analyses plus fréquentes par le nettoyeur, ce qui peut entraîner un trop grand nombre de vidages et d’attrition du cache.
Paramètres de gestion des requêtes et des connexions
Dans Windows Server 2022, HTTP.sys gère automatiquement les connexions. Les paramètres de Registre suivants ne sont plus utilisés :
MaxConnections
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\MaxConnectionsIdleConnectionsHighMark
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsHighMarkIdleConnectionsLowMark
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsLowMarkIdleListTrimmerPeriod
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleListTrimmerPeriodRequestBufferLookasideDepth
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\RequestBufferLookasideDepthInternalRequestLookasideDepth
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\InternalRequestLookasideDepth
Paramètres du mode utilisateur
Les paramètres de cette section affectent le comportement des processus de travail d’IIS 10.0. La plupart de ces paramètres se trouvent dans le fichier de configuration XML suivant :
%SystemRoot%\system32\inetsrv\config\applicationHost.config
Utilisez Appcmd.exe, la console de gestion d’IIS 10.0, ou les cmdlets PowerShell WebAdministration ou IISAdministration pour les modifier. La plupart des paramètres sont détectés automatiquement et ne nécessitent pas de redémarrage des processus de travail ou du serveur d’applications web d’IIS 10.0. Pour plus d’informations sur le fichier applicationHost.config, consultez Présentation de ApplicationHost.config.
Paramètre de processeur idéal pour le matériel NUMA
À compter de Windows Server 2016, IIS 10.0 prend en charge l’affectation automatique du processeur idéal pour ses threads de pool de threads afin d’améliorer les performances et la scalabilité sur le matériel NUMA. Cette fonctionnalité est activée par défaut et peut être configurée via la clé de Registre suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters\ThreadPoolUseIdealCpu
Avec cette fonctionnalité activée, le gestionnaire de threads IIS fait de son mieux pour répartir uniformément les threads du pool de threads IIS entre tous les processeurs de tous les nœuds NUMA, en fonction de leurs charges actuelles. En général, il est recommandé de conserver ce paramètre par défaut inchangé pour le matériel NUMA.
Remarque Le paramètre de processeur idéal est différent des paramètres d’affectation de nœud NUMA du processus de travail (numaNodeAssignment et numaNodeAffinityMode) présentés dans Paramètres de processeur pour un pool d’applications. Le paramètre de processeur idéal affecte la façon dont IIS distribue ses threads de pool de threads, tandis que les paramètres d’affectation de nœud NUMA du processus de travail déterminent le nœud NUMA sur lequel un processus de travail démarre.
Paramètres de comportement du cache en mode utilisateur
Cette section décrit les paramètres qui affectent le comportement de mise en cache dans IIS 10.0. Le cache en mode utilisateur est implémenté sous la forme d’un module qui écoute les événements de mise en cache globale déclenchés par le pipeline intégré. Pour désactiver complètement le cache en mode utilisateur, supprimez le module FileCacheModule (cachfile.dll) de la liste des modules installés dans la section de configuration system.webServer/globalModules du fichier applicationHost.config.
system.webServer/caching
| Attribut | Description | Default |
|---|---|---|
| activé | Désactive le cache IIS en mode utilisateur quand il est défini sur False. Quand le taux de réussite du cache est très faible, vous pouvez désactiver complètement le cache pour éviter la surcharge associée au chemin du code du cache. La désactivation du cache en mode utilisateur ne désactive pas le cache en mode noyau. | True |
| enableKernelCache | Désactive le cache en mode noyau quand il est défini sur False. | True |
| maxCacheSize | Limite la taille du cache en mode utilisateur IIS à la taille spécifiée en mégaoctets. IIS ajuste la valeur par défaut en fonction de la mémoire disponible. Choisissez soigneusement la valeur en fonction de la taille de l’ensemble de fichiers faisant l’objet d’accès fréquents par rapport à la quantité de RAM ou à l’espace d’adressage du processus IIS. | 0 |
| maxResponseSize | Met en cache des fichiers jusqu’à la taille spécifiée. La valeur réelle dépend du nombre et de la taille des fichiers les plus grands dans le jeu de données par rapport à la RAM disponible. La mise en cache de grands fichiers faisant l’objet d’accès fréquents peut réduire l’utilisation du processeur, l’accès au disque et les latences associées. | 262 144 |
Paramètres du comportement de la compression
À compter de sa version 7.0, IIS compresse le contenu statique par défaut. En outre, la compression du contenu dynamique est activée par défaut lors de l’installation de DynamicCompressionModule. La compression réduit l’utilisation de la bande passante, mais augmente l’utilisation du processeur. Le contenu compressé est mis en cache si possible dans le cache en mode noyau. À compter de sa version 8.5, IIS permet de contrôler la compression indépendamment pour le contenu statique et pour le contenu dynamique. Le contenu statique fait généralement référence au contenu qui ne change pas, comme des fichiers GIF ou HTM. Le contenu dynamique est classiquement généré par des scripts ou du code sur le serveur, par exemple des pages ASP.NET. Vous pouvez personnaliser la classification d’une extension particulière comme étant statique ou dynamique.
Pour désactiver complètement la compression, supprimez StaticCompressionModule et DynamicCompressionModule de la liste des modules de la section system.webServer/globalModules dans applicationHost.config.
system.webServer/httpCompression
| Attribut | Description | Default |
|---|---|---|
| staticCompression-EnableCpuUsage staticCompression-DisableCpuUsage dynamicCompression-EnableCpuUsage dynamicCompression-DisableCpuUsage |
Active ou désactive la compression si le pourcentage actuel d’utilisation du processeur passe au-delà ou en deçà des limites spécifiées. À compter d’IIS 7.0, la compression est désactivée automatiquement si le processeur à l’état stable augmente et passe au-delà du seuil de désactivation. La compression est activée si le processeur passe en dessous du seuil d’activation. |
Respectivement 50, 100, 50 et 90 |
| directory | Spécifie le répertoire dans lequel les versions compressées des fichiers statiques sont temporairement stockées et mises en cache. Envisagez de déplacer ce répertoire hors du lecteur système s’il fait l’objet d’accès fréquents. | %SystemDrive%\inetpub\temp\IIS Temporary Compressed Files |
| doDiskSpaceLimiting | Spécifie s’il existe une limite d’espace disque que tous les fichiers compressés peuvent occuper. Les fichiers compressés sont stockés dans le répertoire de compression spécifié par l’attribut directory. | True |
| maxDiskSpaceUsage | Spécifie le nombre d’octets de l’espace disque que les fichiers compressés peuvent occuper dans le répertoire de compression. Il peut être nécessaire d’augmenter ce paramètre si la taille totale de tout le contenu compressé est trop grande. |
100 Mo |
system.webServer/urlCompression
| Attribut | Description | Default |
|---|---|---|
| doStaticCompression | Spécifie si le contenu statique est compressé. | True |
| doDynamicCompression | Spécifie si le contenu dynamique est compressé. | True |
Remarque
Pour les serveurs exécutant IIS 10.0 qui ont une utilisation moyenne du processeur peu élevée, envisagez d’activer la compression du contenu dynamique, en particulier si les réponses sont de grande taille. Ceci doit être effectuée d’abord dans un environnement de test pour évaluer l’effet sur l’utilisation du processeur par rapport à la base de référence.
Optimisation de la liste de documents par défaut
Le module de document par défaut gère les requêtes HTTP pour la racine d’un répertoire et les traduit en requêtes pour un fichier spécifique, comme Default.htm ou Index.htm. En moyenne, environ 25 % de toutes les requêtes sur Internet passent par le chemin du document par défaut. Ceci varie considérablement pour des sites individuels. Quand une requête HTTP ne spécifie pas de nom de fichier, le module de document par défaut recherche chaque nom du système de fichiers dans la liste des documents par défaut autorisés. Cela peut nuire aux performances, en particulier si l’accès au contenu nécessite d’effectuer un aller-retour réseau ou une recherche sur disque.
Vous pouvez éviter la surcharge en désactivant de façon sélective les documents par défaut, et en réduisant ou en triant la liste des documents. Pour les sites web qui utilisent un document par défaut, vous devez réduire la liste en la limitant seulement aux types de documents par défaut utilisés. En outre, triez la liste de sorte qu’elle commence par le nom de fichier du document par défaut qui fait l’objet des accès les plus fréquents.
Vous pouvez définir de façon sélective le comportement du document par défaut sur des URL particulières en personnalisant la configuration avec une étiquette d’emplacement dans applicationHost.config ou en insérant un fichier web.config directement dans le répertoire des contenus. Ceci permet une approche hybride, qui active les documents par défaut seulement là où ils sont nécessaires et définit la liste sur le nom de fichier correct pour chaque URL.
Pour désactiver complètement les documents par défaut, supprimez DefaultDocumentModule de la liste des modules de la section system.webServer/globalModules dans applicationHost.config.
system.webServer/defaultDocument
| Attribut | Description | Default |
|---|---|---|
| enabled | Spécifie que les documents par défaut sont activés. | True |
<files>, élément |
Spécifie les noms de fichiers configurés comme documents par défaut. | La liste par défaut est Default.htm, Default.asp, Index.htm, Index.html, Iisstart.htm et Default.aspx. |
Journalisation binaire centralisée
Quand la session du serveur contient de nombreux groupes d’URL, le processus de création de centaines de fichiers journaux mis en forme pour des groupes d’URL individuels et d’écriture des données de journal sur un disque peut rapidement consommer des ressources de processeur et de mémoire, créant ainsi des problèmes de performances et de scalabilité. La journalisation binaire centralisée réduit au minimum la quantité de ressources système utilisées pour la journalisation, tout en fournissant des données de journal détaillées pour les organisations qui en ont besoin. L’analyse des journaux au format binaire nécessite un outil de post-traitement.
Vous pouvez activer la journalisation binaire centralisée en définissant l’attribut centralLogFileMode sur CentralBinary et en définissant l’attribut enabled sur True. Envisagez de déplacer l’emplacement du fichier journal centralisé en dehors de la partition système et sur un lecteur de journalisation dédié pour éviter la contention entre les activités système et les activités de journalisation.
system.applicationHost/log
| Attribut | Description | Default |
|---|---|---|
| centralLogFileMode | Spécifie le mode de journalisation pour un serveur. Changez cette valeur en CentralBinary pour activer la journalisation binaire centralisée. | Site |
system.applicationHost/log/centralBinaryLogFile
| Attribut | Description | Default |
|---|---|---|
| enabled | Spécifie si la journalisation binaire centralisée est activée. | False |
| directory | Spécifie le répertoire où les entrées de journal sont écrites. | %SystemDrive%\inetpub\logs\LogFiles |
Optimisation des applications et des sites
Les paramètres suivants concernent les optimisations des pools d’applications et des sites.
system.applicationHost/applicationPools/applicationPoolDefaults
| Attribut | Description | Default |
|---|---|---|
| queueLength | Indique à HTTP.sys combien de requêtes sont mises en file d’attente pour un pool d’applications avant que les requêtes futures ne soient rejetées. Quand la valeur de cette propriété est dépassée, IIS rejette les requêtes suivantes avec une erreur 503. Envisagez d’augmenter cette valeur pour les applications qui communiquent avec des magasins de données de back-end à latence élevée si des erreurs 503 sont observées. |
1 000 |
| enable32BitAppOnWin64 | Quand cet attribut est défini sur True, il permet à une application 32 bits de s’exécuter sur un ordinateur doté d’un processeur 64 bits. Envisagez d’activer le mode 32 bits si la consommation de mémoire est un problème. Comme les tailles des pointeurs et des instructions sont plus petites, les applications 32 bits utilisent moins de mémoire que les applications 64 bits. L’inconvénient de l’exécution d’applications 32 bits sur un ordinateur 64 bits est que l’espace d’adressage en mode utilisateur est limité à 4 Go. |
False |
system.applicationHost/sites/VirtualDirectoryDefault
| Attribut | Description | Default |
|---|---|---|
| allowSubDirConfig | Spécifie si IIS recherche des fichiers web.config dans les répertoires de contenus en dessous du niveau actuel (True) ou ne recherche pas de fichiers web.config dans les répertoires de contenus en dessous du niveau actuel (False). En imposant une simple limitation, qui autorise la configuration seulement dans des répertoires virtuels, IIS 10.0 peut savoir que, sauf si /<nom>.htm est un répertoire virtuel, il ne doit pas rechercher un fichier de configuration. Ignorer les opérations de fichier supplémentaires peut considérablement améliorer les performances des sites web qui ont un très grand ensemble de contenu statique accessible faisant l’objet d’accès aléatoires. | True |
Gestion des modules d’IIS 10.0
IIS 10.0 a été factorisé en plusieurs modules extensibles par l’utilisateur pour prendre en charge une structure modulaire. Cette factorisation a induit un petit coût. Pour chaque module, le pipeline intégré doit appeler le module pour chaque événement pertinent pour le module. Ceci se produit indépendamment du fait que le module doit ou non effectuer un travail. Vous pouvez économiser des cycles du processeur et de la mémoire en supprimant tous les modules qui ne sont pas pertinents pour un site web particulier.
Un serveur web qui est optimisé pour des fichiers statiques simples peut inclure seulement les cinq modules suivants : UriCacheModule, HttpCacheModule, StaticFileModule, AnonymousAuthenticationModule et HttpLoggingModule.
Pour supprimer des modules dans applicationHost.config, supprimez toutes les références au module dans les sections system.webServer/handlers et system.webServer/modules, en plus de supprimer la déclaration de module dans system.webServer/globalModules.
Paramètres ASP classiques
Le coût majeur du traitement d’une requête ASP classique comprend l’initialisation d’un moteur de script, la compilation du script ASP demandé en un modèle ASP et l’exécution du modèle sur le moteur de script. Bien que le coût d’exécution du modèle dépende de la complexité du script ASP demandé, le module ASP classique d’IIS peut mettre en cache les moteurs de script dans la mémoire, et mettre en cache les modèles à la fois dans la mémoire et sur disque (seulement si le cache de modèles en mémoire déborde) pour améliorer les performances dans les scénarios liés au processeur.
Les paramètres suivants sont utilisés pour configurer le cache de modèles ASP classiques et le cache de moteurs de script, et ils n’affectent pas les paramètres ASP.NET.
system.webServer/asp/cache
| Attribut | Description | Default |
|---|---|---|
| diskTemplateCacheDirectory | Le nom du répertoire utilisé par ASP pour stocker les modèles compilés quand le cache en mémoire déborde. Recommandation : Définissez un répertoire qui ne fait pas l’objet d’une forte utilisation, par exemple un lecteur qui n’est pas partagé avec le système d’exploitation, le journal IIS ou un autre contenu fréquemment consulté. |
%SystemDrive%\inetpub\temp\ASP Compiled Templates |
| maxDiskTemplateCacheFiles | Spécifie le nombre maximal de modèles ASP compilés qui peuvent être mis en cache sur disque. Recommandation : Définissez la valeur maximale sur 0x7FFFFFFF. |
2000 |
| scriptFileCacheSize | Cet attribut spécifie le nombre maximal de modèles ASP compilés qui peuvent être mis en cache en mémoire. Recommandation : Définissez-le sur une valeur au moins égale au nombre de scripts ASP fréquemment demandés traités par un pool d’applications. Si possible, définissez-le sur une valeur au moins égale au nombre de modèles ASP permis par les limites de la mémoire. |
500 |
| scriptEngineCacheMax | Spécifie le nombre maximal de moteurs de script qui seront mis en cache en mémoire. Recommandation : Définissez-le sur une valeur au moins égale au nombre de scripts ASP fréquemment demandés traités par un pool d’applications. Si possible, définissez-le sur une valeur au moins égale au nombre de moteurs de scripts permis par les limites de la mémoire. |
250 |
system.webServer/asp/limits
| Attribut | Description | Default |
|---|---|---|
| processorThreadMax | Spécifie le nombre maximal de threads de travail par processeur que peut créer ASP. Augmentez sa valeur si le paramètre actuel est insuffisant pour gérer la charge, ce qui peut provoquer des erreurs quand elle traite des requêtes ou entraîner une sous-utilisation des ressources du processeur. | 25 |
system.webServer/asp/comPlus
| Attribut | Description | Default |
|---|---|---|
| executeInMta | Définissez-le sur True si des erreurs ou des échecs sont détectés quand IIS délivre du contenu ASP. Ceci peut se produire par exemple lors de l’hébergement de plusieurs sites isolés où chaque site s’exécute sous son propre processus de travail. Les erreurs sont généralement signalées comme provenant de COM+ dans l’Observateur d’événements. Ce paramètre active le modèle cloisonné multithread dans ASP. | False |
Paramètre de concurrence d’ASP.NET
ASP.NET 3.5
Par défaut, ASP.NET limite la concurrence des requêtes de façon à réduire la consommation de mémoire à l’état stable sur le serveur. Il peut être nécessaire d’ajuster quelques paramètres pour les applications avec une concurrence élevée pour améliorer les performances globales. Vous pouvez modifier ce paramètre dans le fichier aspnet.config :
<system.web>
<applicationPool maxConcurrentRequestsPerCPU="5000"/>
</system.web>
Le paramètre suivant est utile pour utiliser pleinement les ressources sur un système :
maxConcurrentRequestPerCpu Valeur par défaut : 5 000
Ce paramètre limite le nombre maximal de requêtes ASP.NET exécutées en concurrence sur un système. La valeur par défaut est conservatrice pour réduire la consommation de mémoire des applications ASP.NET. Envisagez d’augmenter cette limite sur les systèmes qui exécutent des applications effectuant de longues opérations d’E/S synchrones. Sinon, les utilisateurs peuvent subir une latence élevée en raison d’une mise en file d’attente ou des échecs des requêtes dus au dépassement des limites de la file d’attente sous une charge élevée quand la valeur par défaut est utilisée.
ASP.NET 4.6
Outre le paramètre maxConcurrentRequestPerCpu, ASP.NET 4.7 fournit également des paramètres pour améliorer les performances dans les applications qui dépendent fortement d’opérations asynchrones. Le paramètre peut être modifié dans le fichier aspnet.config.
<system.web>
<applicationPool percentCpuLimit="90" percentCpuLimitMinActiveRequestPerCpu="100"/>
</system.web>
- percentCpuLimit Valeur par défaut : 90. Les requêtes asynchrones ont quelques problèmes de scalabilité quand une charge très importante (au-delà des capacités du matériel) est à traiter dans ce scénario. Le problème est dû à la nature de l’allocation dans les scénarios asynchrones. Dans ces conditions, l’allocation se produit quand l’opération asynchrone démarre, et elle est consommée quand l’opération se termine. À ce moment-là, il est très possible que les objets aient été déplacés vers la génération 1 ou 2 par le GC. Quand cela se produit, l’augmentation de la charge va provoquer une augmentation des requêtes par seconde (rps) jusqu’à un certain point. Une fois ce point passé, le temps passé dans le récupérateur de mémoire commence à devenir un problème et le nombre de requêtes par seconde va commencer à chuter, avec un effet de mise à l’échelle négatif. Pour résoudre le problème, quand l’utilisation du processeur dépasse la valeur de percentCpuLimit, les requêtes sont envoyées à la file d’attente native d’ASP.NET.
- percentCpuLimitMinActiveRequestPerCpu Valeur par défaut : 100. La limitation du processeur (paramètre percentCpuLimit) n’est pas basée sur le nombre de requêtes, mais bien sur leur coût. Par conséquent, il peut y avoir seulement quelques requêtes gourmandes en processeur entraînant une sauvegarde dans la file d’attente native sans aucun moyen de la vider, en dehors des requêtes entrantes. Pour résoudre ce problème, percentCpuLimitMinActiveRequestPerCpu peut être utilisé pour garantir qu’un nombre minimal de requêtes sont traitées avant que la limitation ne se produise.
Processus de travail et options de recyclage
Vous pouvez configurer des options de recyclage des processus de travail IIS, et fournir des solutions pratiques à des situations ou des événements spécifiques, sans qu’une intervention ou une réinitialisation d’un service ou d’un ordinateur soit nécessaire. Ces situations et événements incluent des fuites de mémoire, une augmentation de la charge en mémoire, ou des processus de travail inactifs ou ne répondant pas. Dans des conditions ordinaires, les options de recyclage peuvent ne pas être nécessaires, et le recyclage peut être désactivé ou le système peut être configuré pour recycler très rarement.
Vous pouvez activer le recyclage de processus pour une application particulière en ajoutant des attributs à l’élément recycling/periodicRestart. L’événement de recyclage peut être déclenché par plusieurs événements, y compris l’utilisation de la mémoire, un nombre fixe de requêtes et une période de temps fixe. Quand un processus de travail est recyclé, les requêtes mises en file d’attente et en cours d’exécution sont traitées, et un nouveau processus est démarré simultanément pour traiter les nouvelles requêtes. L’élément recycling/periodicRestart est propre à chaque application, ce qui signifie que chaque attribut du tableau suivant est partitionné par application.
system.applicationHost/applicationPools/ApplicationPoolDefaults/recycling/periodicRestart
| Attribut | Description | Default |
|---|---|---|
| mémoire | Activez le recyclage de processus si la consommation de mémoire virtuelle dépasse la limite spécifiée en Ko. C’est un paramètre utile pour les ordinateurs 32 bits qui ont un petit espace d’adressage de 2 Go. Il peut aider à éviter les échecs des requêtes dus à des erreurs de mémoire insuffisante. | 0 |
| privateMemory | Activez le recyclage de processus si les allocations de mémoire privée dépassent une limite spécifiée en Ko. | 0 |
| requêtes | Activez le recyclage de processus après un certain nombre de requêtes. | 0 |
| time | Activez le recyclage de processus après une période de temps spécifiée. | 29:00:00 |
Optimisation de l’écriture dynamique en page sortante des processus de travail
À compter de Windows Server 2012 R2, IIS offre la possibilité de configurer le processus de travail pour qu’il soit suspendu après avoir été inactif pendant un certain temps (en plus de l’option d’y mettre fin, qui existait depuis IIS 7).
L’objectif principal des fonctionnalités d’écriture en page sortante des processus de travail inactifs et d’arrêt des processus de travail inactifs est de préserver l’utilisation de la mémoire sur le serveur, car un site peut consommer beaucoup de mémoire, même s’il se trouve seulement là, à l’écoute. Selon la technologie utilisée sur le site (contenu statique, ASP.NET ou d’autres frameworks), la mémoire utilisée peut être comprise entre environ 10 Mo et des centaines de Mo, ce qui signifie que si votre serveur est configuré avec de nombreux sites, déterminer les paramètres les plus efficaces pour vos sites peut considérablement améliorer les performances des sites actifs et des sites suspendus.
Avant d’entrer dans les détails, nous devons garder à l’esprit que s’il n’y a aucune contrainte de mémoire, il est probablement préférable de simplement configurer les sites pour qu’ils ne soient jamais suspendus ou arrêtés. Après tout, il n'est guère utile de mettre fin à un processus Worker s'il est le seul sur la machine.
Remarque
Dans le cas où le site exécute du code instable, comme du code avec une fuite de mémoire ou instable pour une autre raison, définir que l’exécution du site doit être arrêtée en cas d’inactivité peut être une alternative « quick-and-dirty » pour résoudre le bogue du code. Ce n’est pas quelque chose que nous encourageons, mais dans une situation critique, il peut être préférable d’utiliser cette fonctionnalité comme mécanisme de nettoyage pendant qu’une solution plus permanente est en cours de développement.]
Un autre facteur à prendre en compte est que si le site utilise beaucoup de mémoire, le processus de mise en suspens lui-même est consommateur de ressources, car l’ordinateur doit écrire les données utilisées par le processus de travail sur le disque. Si le processus de travail utilise une grande quantité de mémoire, sa mise en suspens peut être plus coûteuse que d’attendre qu’il effectue sa sauvegarde.
Pour tirer le meilleur profit de la fonctionnalité de mise en suspens des processus de travail, vous devez passer en revue vos sites dans chaque pool d’applications et déterminer ceux qui doivent être mis en suspens, ceux qui doivent être arrêtés et ceux qui doivent être actifs indéfiniment. Pour chaque action et chaque site, vous devez déterminer le délai d’expiration idéal.
Dans l’idéal, les sites que vous allez configurer pour la mise en suspens ou l’arrêt sont ceux qui ont des visiteurs tous les jours, mais pas assez pour justifier qu’ils soient actifs en permanence. Ce sont généralement des sites avec environ 20 visiteurs uniques par jour ou moins. Vous pouvez analyser les modèles de trafic en utilisant les fichiers journaux du site et calculer le trafic quotidien moyen.
Gardez à l’esprit qu’une fois qu’un utilisateur spécifique se connecte au site, il reste généralement sur celui-ci pendant au moins un certain temps, en effectuant des requêtes supplémentaires : le simple comptage des requêtes quotidiennes peut donc ne pas refléter avec précision les modèles de trafic réels. Pour obtenir une analyse plus précise, vous pouvez aussi utiliser un outil comme Microsoft Excel pour calculer le temps moyen entre les requêtes. Par exemple :
| Number | URL de demande | Heure de la requête | Delta |
|---|---|---|---|
| 1 | /SourceSilverLight/Geosource.web/grosource.html | 10:01 | |
| 2 | /SourceSilverLight/Geosource.web/sliverlight.js | 10:10 | 0:09 |
| 3 | /SourceSilverLight/Geosource.web/clientbin/geo/1.aspx | 10:11 | 0:01 |
| 4 | /lClientAccessPolicy.xml | 10:12 | 0:01 |
| 5 | / SourceSilverLight/GeosourcewebService/Service.asmx | 10:23 | 0:11 |
| 6 | / SourceSilverLight/Geosource.web/GeoSearchServer...¦. | 11 h 50 | 1:27 |
| 7 | /rest/Services/CachedServices/Silverlight_load_la...¦ | 12:50 | 1:00 |
| 8 | /rest/Services/CachedServices/Silverlight_basemap...¦. | 12:51 | 0:01 |
| 9 | /rest/Services/DynamicService/ Silverlight_basemap...¦. | 12:59 | 0:08 |
| 10 | /rest/Services/CachedServices/Ortho_2004_cache.as... | 13:40 | 0:41 |
| 11 | /rest/Services/CachedServices/Ortho_2005_cache.js | 13:40 | 0:00 |
| 12 | /rest/Services/CachedServices/OrthoBaseEngine.aspx | 13:41 | 0:01 |
La partie la plus difficile est cependant de déterminer quel paramètre appliquer pour que cela ait du sens. Dans notre cas, le site reçoit un grand nombre de requêtes des utilisateurs, et le tableau ci-dessus montre qu’un total de 4 sessions uniques se sont produites sur une période de 4 heures. Avec les paramètres par défaut pour la mise en suspens du processus de travail du pool d’applications, le site aurait été arrêté après le délai d’expiration par défaut de 20 minutes, ce qui signifie que chacun de ces utilisateurs subirait le cycle de démarrage du site. Ceci en fait un candidat idéal pour la mise en suspens du processus de travail, car la plupart du temps, le site est inactif : sa mise en suspens permettrait donc d’économiser les ressources et permettrait aux utilisateurs d’accéder au site quasi instantanément.
Une dernière remarque très importante à ce sujet est que les performances du disque sont cruciales pour cette fonctionnalité. Comme le processus de mise en suspens et de réveil implique l’écriture et la lecture d’une grande quantité de données sur le disque dur, nous vous recommandons vivement d’utiliser pour cela un disque rapide. Les disques SSD sont idéaux et fortement recommandés pour cela, et vous devez vérifier que le fichier d’échange Windows y est stocké (si le système d’exploitation lui-même n’est pas installé sur le disque SSD, configurez le système d’exploitation pour y déplacer le fichier d’échange).
Que vous utilisiez ou non un disque SSD, nous vous recommandons également de fixer la taille du fichier d’échange pour prendre en charge l’écriture des données des pages sortantes dans celui-ci sans nécessiter le redimensionnement du fichier. Le redimensionnement du fichier d’échange peut se produire quand le système d’exploitation doit stocker des données dans le fichier d’échange, car par défaut, Windows est configuré pour ajuster automatiquement sa taille en fonction des besoins. En définissant la taille sur une taille fixe, vous pouvez empêcher le redimensionnement et améliorer considérablement les performances.
Pour configurer une taille de fichier d’échange prédéfinie, vous devez calculer sa taille idéale, qui dépend du nombre de sites que vous allez mettre en suspens et de la quantité de mémoire qu’ils consomment. Si la moyenne est de 200 Mo pour un processus de travail actif et que vous avez 500 sites qui seront mis en suspens sur les serveurs, le fichier d’échange doit être d’au moins (200 * 500) Mo en plis de la taille de base du fichier d’échange (donc dans notre exemple, la taille base + 100 Go).
Remarque
Quand des sites sont mis en suspens, ils consomment environ 6 Mo chacun, donc dans notre cas, l’utilisation de la mémoire si tous les sites sont mis en suspens est d’environ 3 Go. Dans les faits, cependant, vous ne pourrez probablement jamais les suspendre tous en même temps.
Paramètres d’optimisation de TLS (Transport Layer Security)
L’utilisation du protocole TLS (Transport Layer Security) impose un coût processeur supplémentaire. Le composant le plus coûteux de TLS est le coût d’établissement d’une session, car il implique une négociation complète. La reconnexion, le chiffrement et le déchiffrement ajoutent également au coût. Pour de meilleures performances de TLS, effectuez les actions suivantes :
Activez les connexions HTTP persistantes pour les sessions TLS. Ceci élimine les coûts d’établissement des sessions.
Réutilisez les sessions quand c’est approprié, en particulier avec du trafic non persistant.
Appliquez le chiffrement de façon sélective seulement aux pages ou aux parties du site qui en ont besoin, plutôt qu’à l’ensemble du site.
Notes
- Les clés plus longues offrent plus de sécurité, mais elles utilisent également plus de temps processeur.
- Tous les composants n’ont peut-être pas besoin d’être chiffrés. Cependant, la combinaison de HTTP simple et de HTTPS peut provoquer l’affichage d’un avertissement indiquant que tout le contenu de la page n’est pas sécurisé.
ISAPI (Internet Server Application Programming Interface)
Aucun paramètre d’optimisation spécial n’est nécessaire pour les applications ISAPI. Si vous écrivez une extension ISAPI privée, veillez à l’écrire pour optimiser les performances et l’utilisation des ressources.
Conseils d’optimisation du code managé
Le modèle de pipeline intégré dans IIS 10.0 offre un haut degré de flexibilité et d’extensibilité. Les modules personnalisés implémentés dans du code natif ou managé peuvent être insérés dans le pipeline ou remplacer des modules existants. Bien que ce modèle d’extensibilité offre commodité et simplicité, vous devez être prudent avant d’insérer de nouveaux modules managés qui se connectent à des événements globaux. L’ajout d’un module managé global signifie que toutes les requêtes, y compris les demandes de fichiers statiques, doivent appeler du code managé. Les modules personnalisés sont sensibles à des événements comme le nettoyage de la mémoire. En outre, les modules personnalisés ajoutent un coût processeur important en raison du marshaling des données entre le code natif et le code managé. Si c’est possible, définissez preCondition sur managedHandler pour le module managé.
Pour obtenir de meilleures performances de démarrage à froid, veillez à précompiler le site web ASP.NET ou à tirer parti de la fonctionnalité d’initialisation d’application IIS pour préparer l’application.
Si l’état de la session n’est pas nécessaire, veillez à le désactiver pour chaque page.
S’il y a de nombreuses opérations liées aux E/S, essayez d’utiliser la version asynchrone des API pertinentes, ce qui vous donnera une bien meilleure scalabilité.
Une utilisation appropriée du cache de sortie accélère également les performances de votre site web.
Quand vous exécutez plusieurs hôtes qui contiennent des scripts ASP.NET en mode isolé (un pool d’applications par site), superviser l’utilisation de la mémoire. Vérifiez que le serveur dispose de suffisamment de RAM pour le nombre attendu de pools d’applications s’exécutant simultanément. Envisagez d’utiliser plusieurs domaines d’application au lieu de plusieurs processus isolés.
Autres problèmes affectant les performances d’IIS
Les problèmes suivants peuvent affecter les performances d’IIS :
Installation de filtres qui ne prennent pas en compte le cache
L’installation d’un filtre qui ne prend pas en charge le cache HTTP provoque la désactivation complète de la mise en cache par IIS, ce qui entraîne des performances médiocres. Les filtres ISAPI écrits avant IIS 6.0 peuvent provoquer ce comportement.
Requêtes CGI (Common Gateway Interface)
Pour des raisons de performances, l’utilisation d’applications CGI pour traiter les requêtes n’est pas recommandée avec IIS. La création et la suppression fréquentes de processus CGI impliquent une surcharge importante. Parmi les meilleures alternatives, vous pouvez utiliser FastCGI, des scripts d’application ISAPI, et des scripts ASP ou ASP.NET. L’isolation est disponible pour chacune de ces options.