Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Internet Information Services (IIS) 10.0 est inclus avec Windows Server 2022. Il utilise un modèle de processus similaire à celui d’IIS 8.5 et IIS 7.0. Un pilote Web en mode noyau (http.sys) reçoit et achemine les requêtes HTTP et les satisfait à partir de son cache de réponses. Les processus de travail s’enregistrent pour les sous-espaces d’URL et acheminent http.sys la demande vers le processus approprié (ou l’ensemble de processus pour les pools d’applications).
HTTP.sys est responsable de la gestion des connexions et du traitement des demandes. La demande peut être servie à partir du cache HTTP.sys ou transmise à un processus de travail pour un traitement ultérieur. Plusieurs processus de travail peuvent être configurés, ce qui permet une isolation à moindre coût. Pour plus d’informations sur le fonctionnement de la gestion des demandes, consultez la figure suivante :
HTTP.sys inclut un cache de réponses. Lorsqu’une requête correspond à une entrée dans le cache de réponses, HTTP.sys envoie la réponse de cache directement à partir du mode noyau. Certaines plates-formes d’applications Web, telles que ASP.NET, fournissent des mécanismes permettant de mettre en cache tout contenu dynamique dans le cache en mode noyau. Le gestionnaire de fichiers statiques d’IIS 10.0 met automatiquement en cache les fichiers fréquemment demandés dans http.sys.
Étant donné qu’un serveur Web comporte des composants en mode noyau et en mode utilisateur, les deux composants doivent être réglés pour des performances optimales. Par conséquent, le réglage 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é
Processus de travail et IIS en mode utilisateur, y compris la configuration du pool d’applications
Certains paramètres de réglage qui affectent les performances
Les sections suivantes expliquent comment configurer les aspects en mode noyau et en 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 demandes. Tous les paramètres de registre sont stockés sous l’entrée de registre suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters
Note Si le service HTTP est déjà en cours d’exécution, vous devez le redémarrer pour que les modifications soient prises en compte.
Paramètres de gestion du cache
L’un des avantages de HTTP.sys est 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 du processeur pour le traitement de la demande. Toutefois, 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’est utile que lorsqu’elle est utilisée. Cependant, l’entrée consomme toujours de la mémoire physique, qu’elle soit utilisée ou non. Vous devez évaluer l’utilité d’un élément dans le cache (les économies réalisées grâce à la possibilité de le servir à 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 de charge de travail. HTTP.sys essaie de ne conserver que les éléments utiles et activement consultés dans le cache, mais vous pouvez augmenter les performances du serveur Web en ajustant le cache HTTP.sys pour des charges de travail particulières.
Voici quelques paramètres utiles pour le cache en mode noyau HTTP.sys :
UriEnableCache Valeur par défaut : 1
Une valeur non nulle 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 prévoyez une réponse très faible et une mise en cache de fragments.
UriMaxCacheMegabyteCount Valeur par défaut : 0
Valeur non nulle 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.
Note Si vous spécifiez la taille, vous ne définissez que la taille maximale, et le système risque de ne pas laisser le cache atteindre la taille maximale définie.
Â
UriMaxUriBytes Valeur par défaut : 262144 octets (256 Ko)
Taille maximale d’une entrée dans le cache en mode noyau. Les réponses ou les fragments plus volumineux ne sont pas mis en cache. Si vous disposez de suffisamment de mémoire, envisagez d’augmenter la limite. Si la mémoire est limitée et que les entrées volumineuses évincent les plus petites, il peut être utile de réduire la limite.
Période UriScavenger Valeur par défaut : 120 secondes
Le cache HTTP.sys est analysé périodiquement par un charognard, et les entrées qui ne sont pas accessibles entre les balayages sont supprimées. Le fait de définir la période de récupération sur une valeur élevée réduit le nombre de balayages de récupération. Toutefois, l’utilisation de la mémoire cache peut augmenter, car les entrées plus anciennes et moins fréquemment consultées peuvent rester dans le cache. Si la période est trop basse, les analyses de récupération sont plus fréquentes et peuvent entraîner un trop grand nombre de vidages et d’attrition du cache.
Paramètres de gestion des demandes 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\IdleConnectionsLowMarkPériode IdleListTrimmer
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 du processus de travail 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 IIS 10.0, WebAdministration ou les applets de commande PowerShell 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 IIS 10.0 ou du serveur d’applications Web. Pour plus d’informations sur le fichier applicationHost.config, voir Présentation de ApplicationHost.config.
Réglage idéal du processeur pour le matériel NUMA
À partir de Windows Server 2016, IIS 10.0 prend en charge l’attribution automatique idéale du processeur pour ses threads de pool de threads afin d’améliorer les performances et l’évolutivité 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
Lorsque cette fonctionnalité est activée, le gestionnaire de threads IIS fait de son mieux pour répartir uniformément les threads du pool de threads IIS sur 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.
Note 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) introduits dans les paramètres de processeur d’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’attribution de nœud NUMA du processus de travail déterminent sur quel nœud NUMA 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 la 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 globaux qui sont 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 dans applicationHost.config.
system.webServer/mise en cache
| Caractéristique | Descriptif | Par défaut |
|---|---|---|
| Activé | Désactive le cache IIS en mode utilisateur lorsqu’il est défini sur False. Lorsque le taux d’accès au cache est très faible, vous pouvez désactiver complètement le cache pour éviter la surcharge associée au chemin d’accès au code du cache. La désactivation du cache en mode utilisateur ne désactive pas le cache en mode noyau. | Vrai |
| enableKernelCache | Désactive le cache en mode noyau lorsqu’il est défini sur False. | Vrai |
| 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 la valeur avec soin en fonction de la taille de l’ensemble des fichiers fréquemment consultés par rapport à la quantité de RAM ou à l’espace d’adressage du processus IIS. | 0 |
| maxResponseSize | Met en cache les fichiers jusqu’à la taille spécifiée. La valeur réelle dépend du nombre et de la taille des fichiers les plus volumineux de l’ensemble de données par rapport à la RAM disponible. La mise en cache de fichiers volumineux et fréquemment demandés peut réduire l’utilisation du processeur, l’accès au disque et les latences associées. | 262144 |
Paramètres de comportement de compression
IIS à partir de la version 7.0 compresse le contenu statique par défaut. En outre, la compression du contenu dynamique est activée par défaut lorsque le DynamicCompressionModule est installé. La compression réduit l’utilisation de la bande passante, mais augmente l’utilisation du processeur. Le contenu compressé est mis en cache dans le cache en mode noyau si possible. À partir de la version 8.5, IIS permet de contrôler indépendamment la compression pour le contenu statique et dynamique. Le contenu statique fait généralement référence au contenu qui ne change pas, comme les fichiers GIF ou HTM. Le contenu dynamique est généralement généré par des scripts ou du code sur le serveur, c’est-à-dire ASP.NET pages. Vous pouvez personnaliser la classification d’une extension particulière en tant que 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
| Caractéristique | Descriptif | Par défaut |
|---|---|---|
| staticCompression-EnableCpuUsage staticCompression-DisableCpuUsage dynamicCompression-EnableCpuUsage dynamicCompression-DisableCpuUsage |
Active ou désactive la compression si le pourcentage actuel d’utilisation du processeur dépasse ou descend en dessous des limites spécifiées. À partir d’IIS 7.0, la compression est automatiquement désactivée si le processeur à l’état stable dépasse le seuil de désactivation. La compression est activée si le processeur tombe en dessous du seuil d’activation. |
50, 100, 50 et 90 respectivement |
| répertoire | 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 du lecteur système s’il est consulté fréquemment. | %SystemDrive%Fichiers compressés temporaires \inetpub\temp\IIS |
| doDiskSpaceLimiting | Spécifie s’il existe une limite pour la quantité 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 . | Vrai |
| maxDiskSpaceUsage | Spécifie le nombre d’octets d’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 importante. |
100 Mo |
system.webServer/urlCompression
| Caractéristique | Descriptif | Par défaut |
|---|---|---|
| doStaticCompression | Spécifie si le contenu statique est compressé. | Vrai |
| doDynamicCompression | Spécifie si le contenu dynamique est compressé. | Vrai |
Remarque
Pour les serveurs exécutant IIS 10.0 qui ont une faible utilisation moyenne du processeur, envisagez d’activer la compression pour le contenu dynamique, en particulier si les réponses sont volumineuses. Cela doit d’abord être fait dans un environnement de test pour évaluer l’effet sur l’utilisation du processeur à partir de la ligne de base.
Réglage 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, tel que Default.htm ou Index.htm. En moyenne, environ 25 % de toutes les requêtes sur Internet passent par le chemin d’accès au document par défaut. Cela varie considérablement d’un site à l’autre. Lorsqu’une requête HTTP ne spécifie pas de nom de fichier, le module de document par défaut recherche chaque nom dans le 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 de toucher un disque.
Vous pouvez éviter la surcharge en désactivant de manière sélective les documents par défaut et en réduisant ou en ordonnant la liste des documents. Pour les sites Web qui utilisent un document par défaut, vous devez réduire la liste aux seuls types de documents par défaut utilisés. De plus, organisez la liste de manière à ce qu’elle commence par le nom de fichier de document par défaut le plus fréquemment consulté.
Vous pouvez définir de manière sélective le comportement par défaut du document sur des URL particulières en personnalisant la configuration à l’intérieur d’une balise d’emplacement dans applicationHost.config ou en insérant un fichier web.config directement dans le répertoire de contenu. Cela permet une approche hybride, qui active les documents par défaut uniquement lorsqu’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
| Caractéristique | Descriptif | Par défaut |
|---|---|---|
| Activé | Spécifie que les documents par défaut sont activés. | Vrai |
élément <files> |
Spécifie les noms de fichiers configurés en tant que documents par défaut. | La liste par défaut est Default.htm, Default.asp, Index.htm, Index.html, Iisstart.htmet Default.aspx. |
Journalisation binaire centralisée
Lorsque la session serveur comporte de nombreux groupes d’URL, le processus de création de centaines de fichiers journaux formatés pour des groupes d’URL individuels et d’écriture des données de journal sur un disque peut rapidement consommer de précieuses ressources de processeur et de mémoire, créant ainsi des problèmes de performances et d’évolutivité. La journalisation binaire centralisée minimise la quantité de ressources système utilisées pour la journalisation, tout en fournissant des données de journal détaillées aux 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 centrale en définissant l’attribut centralLogFileMode sur CentralBinary et l’attribut enabled sur True. Envisagez de déplacer l’emplacement du fichier journal central de la partition système vers un lecteur de journalisation dédié afin d’éviter les conflits entre les activités système et les activités de journalisation.
system.applicationHost/log
| Caractéristique | Descriptif | Par défaut |
|---|---|---|
| centralLogFileMode | Spécifie le mode de journalisation d’un serveur. Remplacez cette valeur par CentralBinary pour activer la journalisation binaire centrale. | Site |
system.applicationHost/log/centralBinaryLogFile
| Caractéristique | Descriptif | Par défaut |
|---|---|---|
| Activé | Spécifie si la journalisation binaire centrale est activée. | Faux |
| répertoire | Spécifie le répertoire dans lequel les entrées de journal sont écrites. | %SystemDrive%\inetpub\logs\LogFiles |
Réglages d’applications et de sites
Les paramètres suivants concernent le pool d’applications et les réglages de site.
system.applicationHost/applicationPools/applicationPoolDefaults
| Caractéristique | Descriptif | Par défaut |
|---|---|---|
| queueLength | Indique à HTTP.sys combien de demandes sont mises en file d’attente pour un pool d’applications avant que les demandes futures ne soient rejetées. Lorsque la valeur de cette propriété est dépassée, IIS rejette les demandes suivantes avec une erreur 503. Envisagez d’augmenter cette valeur pour les applications qui communiquent avec des magasins de données back-end à latence élevée si des erreurs 503 sont observées. |
1 000 |
| enable32BitAppOnWin64 | Lorsque la valeur est true, 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. Étant donné que la taille des pointeurs et des instructions est plus petite, 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. |
Faux |
system.applicationHost/sites/VirtualDirectoryDefault
| Caractéristique | Descriptif | Par défaut |
|---|---|---|
| allowSubDirConfig | Spécifie si IIS recherche les fichiers web.config dans les répertoires de contenu inférieurs au niveau actuel (True) ou ne recherche pas les fichiers web.config dans les répertoires de contenu inférieurs au niveau actuel (False). En imposant une limitation simple, qui n’autorise la configuration que dans les répertoires virtuels, IISÂ 10.0 peut savoir que, à moins que /<name>.htm ne soit un répertoire virtuel, il ne doit pas rechercher de fichier de configuration. L’ignorance des opérations de fichier supplémentaires peut améliorer considérablement les performances des sites Web qui ont un très grand ensemble de contenu statique accessible de manière aléatoire. | Vrai |
Gestion des modules IIS 10.0
IIS 10.0 a été intégré dans plusieurs modules extensibles par l’utilisateur pour prendre en charge une structure modulaire. Cette factorisation a un faible coût. Pour chaque module, le pipeline intégré doit appeler le module pour chaque événement pertinent pour le module. Cela se produit, que le module doive ou non effectuer un travail. Vous pouvez économiser les cycles de processeur et la mémoire en supprimant tous les modules qui ne sont pas pertinents pour un site Web particulier.
Un serveur Web configuré pour des fichiers statiques simples peut inclure uniquement les cinq modules suivants : UriCacheModule, HttpCacheModule, StaticFileModule, AnonymousAuthenticationModule et HttpLoggingModule.
Pour supprimer des modules de applicationHost.config, supprimez toutes les références au module des sections system.webServer/handlers et system.webServer/modules, en plus de supprimer la déclaration du module dans system.webServer/globalModules.
Paramètres ASP classiques
Le coût principal du traitement d’une requête ASP classique comprend l’initialisation d’un moteur de script, la compilation du script ASP demandé dans 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 IIS peut mettre en cache les moteurs de script en mémoire et mettre en cache les modèles en mémoire et sur le disque (uniquement en cas de dépassement du cache de modèle en mémoire) 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èle ASP classique et le cache du moteur de script, et ils n’affectent pas ASP.NET paramètres.
system.webServer/asp/cache
| Caractéristique | Descriptif | Par défaut |
|---|---|---|
| diskTemplateCacheDirectory | Nom du répertoire qu’ASP utilise pour stocker les modèles compilés en cas de dépassement du cache en mémoire. Recommandation : Définissez sur un répertoire qui n’est pas très utilisé, par exemple, un lecteur qui n’est pas partagé avec le système d’exploitation, le journal IIS ou tout autre contenu fréquemment consulté. |
%SystemDrive%Modèles compilés \inetpub\temp\ASP |
| maxDiskTemplateCacheFiles | Spécifie le nombre maximal de modèles ASP compilés qui peuvent être mis en cache sur le disque. Recommandation : Définissez la valeur maximale de 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 au moins le nombre de scripts ASP fréquemment demandés servis par un pool d’applications. Si possible, définissez autant de modèles ASP que les limites de mémoire le permettent. |
500 |
| scriptEngineCacheMax | Spécifie le nombre maximal de moteurs de script qui seront conservés en mémoire cache. Recommandation : Définissez au moins le nombre de scripts ASP fréquemment demandés servis par un pool d’applications. Si possible, définissez autant de moteurs de script que la limite de mémoire le permet. |
250 |
system.webServer/asp/limits
| Caractéristique | Descriptif | Par défaut |
|---|---|---|
| processeurThreadMax | Spécifie le nombre maximal de threads de travail par processeur que ASP peut créer. Augmentez si le paramètre actuel est insuffisant pour gérer la charge, ce qui peut provoquer des erreurs lors du traitement des demandes ou entraîner une sous-utilisation des ressources CPU. | 25 |
system.webServer/asp/comPlus
| Caractéristique | Descriptif | Par défaut |
|---|---|---|
| executeInMta | Définissez la valeur True si des erreurs ou des échecs sont détectés pendant qu’IIS diffuse du contenu ASP. Cela peut se produire, par exemple, lors de l’hébergement de plusieurs sites isolés dans lesquels chaque site s’exécute sous son propre processus de travail. Les erreurs sont généralement signalées à partir de COM+ dans l’Observateur d’événements. Ce paramètre active le modèle cloisonné multithread dans ASP. | Faux |
ASP.NET paramètre de simultanéité
ASP.NET 3.5
Par défaut, ASP.NET limite la simultanéité des requêtes pour réduire la consommation de mémoire à l’état stable sur le serveur. Les applications à concurrence élevée peuvent avoir besoin d’ajuster certains paramètres pour améliorer les performances globales. Vous pouvez modifier ce paramètre dans aspnet.config fichier :
<system.web>
<applicationPool maxConcurrentRequestsPerCPU="5000"/>
</system.web>
Le paramètre suivant est utile pour utiliser pleinement les ressources d’un système :
maxConcurrentRequestPerCpu Valeur par défaut : 5000
Ce paramètre limite le nombre maximal de demandes de ASP.NET exécutées simultanément 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 qui effectuent des opérations d’E/S longues et synchronisées. Sinon, les utilisateurs peuvent rencontrer une latence élevée en raison d’échecs de mise en file d’attente ou de demandes en raison du dépassement des limites de file d’attente sous une charge élevée lorsque le paramètre par défaut est utilisé.
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 reposent fortement sur le fonctionnement asynchrone. Le paramètre peut être modifié dans aspnet.config fichier.
<system.web>
<applicationPool percentCpuLimit="90" percentCpuLimitMinActiveRequestPerCpu="100"/>
</system.web>
- percentCpuLimit Valeur par défaut : 90 La requête asynchrone présente des problèmes d’évolutivité lorsqu’une charge énorme (au-delà des capacités matérielles) est appliquée à un tel scénario. Le problème est dû à la nature de l’allocation sur des scénarios asynchrones. Dans ces conditions, l’allocation aura lieu au démarrage de l’opération asynchrone et elle sera consommée à la fin de l’opération. À 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 GC. Lorsque cela se produit, l’augmentation de la charge affichera une augmentation sur demande par seconde (rps) jusqu’à un certain point. Une fois que nous dépassons ce point, le temps passé en GC commencera à devenir un problème et les rps commenceront à baisser, ce qui aura un effet de mise à l’échelle négatif. Pour résoudre le problème, lorsque l’utilisation du processeur dépasse le paramètre percentCpuLimit, les demandes sont envoyées à la file d’attente native ASP.NET.
- percentCpuLimitMinActiveRequestPerCpu Valeur par défaut : 100 La limitation du processeur (paramètre percentCpuLimit) n’est pas basée sur le nombre de demandes, mais sur leur coût. Par conséquent, il peut n’y avoir que quelques requêtes gourmandes en ressources CPU provoquant 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 s’assurer qu’un nombre minimum de demandes sont traitées avant que la limitation n’entre en jeu.
Processus des travailleurs 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 aigus sans nécessiter d’intervention ou de réinitialisation d’un service ou d’un ordinateur. Ces situations et événements incluent des fuites de mémoire, une augmentation de la charge de mémoire ou des processus de travail qui ne répondent pas ou qui sont inactifs. Dans des conditions normales, 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 des 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, notamment l’utilisation de la mémoire, un nombre fixe de requêtes et une période de temps fixe. Lorsqu’un processus de travail est recyclé, les demandes en file d’attente et en cours d’exécution sont drainées, et un nouveau processus est démarré simultanément pour traiter les nouvelles demandes. L’élément recycling/periodicRestart est par application, ce qui signifie que chaque attribut du tableau suivant est partitionné par application.
system.applicationHost/applicationPools/ApplicationPoolDefaults/recycling/periodicRestart
| Caractéristique | Descriptif | Par défaut |
|---|---|---|
| mémoire | Activez le recyclage des processus si la consommation de mémoire virtuelle dépasse la limite spécifiée en kilo-octets. Il s’agit d’un paramètre utile pour les ordinateurs 32 bits qui disposent d’un petit espace d’adressage de 2 Go. Cela peut aider à éviter les demandes échouées dues à des erreurs de mémoire insuffisante. | 0 |
| privateMemory | Activez le recyclage des processus si les allocations de mémoire privée dépassent une limite spécifiée en kilo-octets. | 0 |
| Requêtes | Activez le recyclage du processus après un certain nombre de demandes. | 0 |
| Heure | Activez le recyclage du processus après une période de temps spécifiée. | 29:00:00 |
Réglage dynamique de la sortie de page du 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 qu’il ait été inactif pendant un certain temps (en plus de l’option d’arrêt, qui existait depuis IIS 7).
L’objectif principal des fonctionnalités de sortie de page et de fin de processus de travail inactif est de conserver l’utilisation de la mémoire sur le serveur, car un site peut consommer beaucoup de mémoire même s’il est simplement assis là à écouter. Selon la technologie utilisée sur le site (contenu statique ASP.NET vs autres frameworks), la mémoire utilisée peut aller d’environ 10 Mo à 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 améliorer considérablement les performances des sites actifs et suspendus.
Avant d’entrer dans les détails, nous devons garder à l’esprit que s’il n’y a pas de contraintes de mémoire, il est probablement préférable de simplement configurer les sites pour qu’ils ne soient jamais suspendus ou terminés. Après tout, il n’y a pas beaucoup d’intérêt à mettre fin à un processus de travail s’il est le seul sur la machine.
Remarque
Dans le cas où le site exécute un code instable, tel qu’un code avec une fuite de mémoire, ou autrement instable, la configuration du site pour qu’il se termine en mode inactif peut être une alternative rapide et sale à la correction du bogue de code. Ce n’est pas quelque chose que nous encouragerions, mais en cas de crise, il serait peut-être préférable d’utiliser cette fonctionnalité comme mécanisme de nettoyage pendant qu’une solution plus permanente est en préparation.]
Un autre facteur à prendre en compte est que si le site utilise beaucoup de mémoire, le processus de suspension lui-même en a un impact, 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 partie de la mémoire, sa suspension peut être plus coûteuse que le coût d’attendre qu’il redémarre.
Pour tirer le meilleur parti de la fonctionnalité de suspension du processus de travail, vous devez examiner vos sites dans chaque pool d’applications et décider lesquels doivent être suspendus, lesquels doivent être terminés et lesquels doivent être actifs indéfiniment. Pour chaque action et chaque site, vous devez déterminer le délai d’attente idéal.
Idéalement, les sites que vous configurerez pour la suspension ou la résiliation sont ceux qui ont des visiteurs tous les jours, mais pas assez pour justifier de le garder actif tout le temps. Il s’agit généralement de sites avec environ 20 visiteurs uniques par jour ou moins. Vous pouvez analyser les modèles de trafic à l’aide des 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 y restera généralement pendant au moins un certain temps, faisant des demandes supplémentaires, et donc le simple fait de compter les demandes quotidiennes peut ne pas refléter avec précision les modèles de trafic réels. Pour obtenir une lecture plus précise, vous pouvez également utiliser un outil, tel que Microsoft Excel, pour calculer le temps moyen entre les demandes. Par exemple:
| Numéro | URL de requête | Heure de la demande | 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:50 | 1:27 |
| 7 | /rest/Services/CachedServices/Silverlight_load_la...¦ | 1,250 | 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, cependant, est de déterminer quel paramètre appliquer pour avoir un sens. Dans notre cas, le site reçoit un tas de requêtes d’utilisateurs, et le tableau ci-dessus montre qu’un total de 4 sessions uniques ont eu lieu sur une période de 4 heures. Avec les paramètres par défaut pour la suspension du processus de travail du pool d’applications, le site serait arrêté après le délai d’expiration par défaut de 20 minutes, ce qui signifie que chacun de ces utilisateurs connaîtrait le cycle de rotation du site. Cela en fait un candidat idéal pour la suspension des processus de travail, car la plupart du temps, le site est inactif, et donc le suspendre permettrait d’économiser des ressources et de permettre aux utilisateurs d’accéder au site presque instantanément.
Une dernière remarque très importante à ce sujet est que les performances du disque sont cruciales pour cette fonctionnalité. Étant donné que le processus de suspension 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 un disque rapide pour cela. Les disques SSD sont idéaux et fortement recommandés pour cela, et vous devez vous assurer que le fichier d’échange Windows y est stocké (si le système d’exploitation lui-même n’est pas installé sur le SSD, configurez le système d’exploitation pour y déplacer le fichier d’échange).
Que vous utilisiez un SSD ou non, nous vous recommandons également de fixer la taille du fichier d’échange pour permettre l’écriture des données de sortie de page dans celui-ci sans redimensionnement du fichier. Le redimensionnement du fichier d’échange peut se produire lorsque 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 suspendre 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 sur les serveurs qui seront suspendus, le fichier d’échange doit dépasser d’au moins (200 * 500) Mo la taille de base du fichier d’échange (donc base + 100 Go dans notre exemple).
Remarque
Lorsque les sites sont suspendus, ils consomment environ 6 Mo chacun, donc dans notre cas, l’utilisation de la mémoire si tous les sites sont suspendus serait d’environ 3 Go. En réalité, cependant, vous ne les aurez probablement jamais tous suspendus en même temps.
Paramètres de réglage de la sécurité de la couche de transport
L’utilisation de TLS (Transport Layer Security) impose un coût supplémentaire pour le processeur. Le composant le plus coûteux de TLS est le coût de l’établissement d’une session, car il implique une poignée de main complète. La reconnexion, le cryptage et le décryptage augmentent également le coût. Pour de meilleures performances TLS, procédez comme suit :
Activez les keep-alives HTTP pour les sessions TLS. Cela élimine les coûts d’établissement de la session.
Réutilisez les sessions le cas échéant, en particulier avec le trafic non persistant.
Appliquez le chiffrement de manière sélective uniquement aux pages ou aux parties du site qui en ont besoin, plutôt qu’à l’ensemble du site.
Remarque
- Les clés plus grandes offrent plus de sécurité, mais elles utilisent également plus de temps CPU.
- Il n’est peut-être pas nécessaire de chiffrer tous les composants. Toutefois, le mélange de HTTP simple et de HTTPS peut entraîner l’affichage d’une fenêtre contextuelle indiquant que tout le contenu de la page n’est pas sécurisé.
Interface de programmation d’applications de serveur Internet (ISAPI)
Aucun paramètre de réglage spécial n’est nécessaire pour les applications ISAPI. Si vous écrivez une extension ISAPI privée, assurez-vous qu’elle est écrite pour les performances et l’utilisation des ressources.
Instructions de réglage 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 gérés qui se connectent à des événements globaux. L’ajout d’un module managé global signifie que toutes les requêtes, y compris les requêtes de fichiers statiques, doivent toucher le code managé. Les modules personnalisés sont sensibles à des événements tels que le nettoyage de la mémoire. En outre, les modules personnalisés ajoutent un coût CPU important en raison du marshaling des données entre le code natif et le code managé. Si possible, vous devez définir preCondition sur managedHandler pour le module géré.
Pour obtenir de meilleures performances de démarrage à froid, assurez-vous de précompiler le site Web ASP.NET ou d’utiliser la fonctionnalité d’initialisation de l’application IIS pour réchauffer l’application.
Si l’état de la session n’est pas nécessaire, assurez-vous de le désactiver pour chaque page.
S’il y a beaucoup d’opérations liées aux E/S, essayez d’utiliser une version asynchrone des API pertinentes qui vous donnera une bien meilleure évolutivité.
De plus, l’utilisation correcte du cache de sortie améliorera également les performances de votre site Web.
Lorsque vous exécutez plusieurs hôtes contenant des scripts ASP.NET en mode isolé (un pool d’applications par site), surveillez l’utilisation de la mémoire. Assurez-vous que le serveur dispose de suffisamment de RAM pour le nombre prévu de pools d’applications en cours d’exécution simultanée. 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 IIS :
Installation de filtres qui ne prennent pas en charge le cache
L’installation d’un filtre qui n’est pas compatible avec le cache HTTP entraîne la désactivation complète de la mise en cache par IIS, ce qui entraîne des performances médiocres. Les filtres ISAPI qui ont été écrits avant IISÂ 6.0 peuvent provoquer ce comportement.
Demandes CGI (Common Gateway Interface)
Pour des raisons de performances, l’utilisation d’applications CGI pour traiter les demandes n’est pas recommandée avec IIS. La création et la suppression fréquentes de processus CGI impliquent des frais généraux importants. De meilleures alternatives incluent l’utilisation de FastCGI, des scripts d’application ISAPI et des scripts ASP ou ASP.NET. L’isolation est disponible pour chacune de ces options.