Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Atteint de JavaScriptite Aiguë [Cyril Durand]

Expert ASP.net Ajax et WCF, Cyril Durand parle dans son blog de point techniques sur ASP.net, ASP.net Ajax, JavaScript, WCF et .net en général. Cyril est également consultant indépendant, n'hésitez pas à le contacter pour de l'assistance sur vos projets

Actualités

  • Blog de Cyril DURAND, passionné de JavaScript, Ajax, ASP.net et tout ce qui touche au developpement Web Client-Side.

    N'hésitez pas à me contacter pour vos projets .net : architecture, accompagnement, formation, ...

    View Cyril Durand's profile on LinkedIn
    hit counters


    Expertise Commerce server et BizTalk

IIS7 – Compression GZIP

La compression GZIP permet d’améliorer les performances de navigation en compressant ce qu’envoie le serveur à un client.

Pour comprendre comment cela fonctionne, regardons ce qu’il se passe au niveau HTTP lorsqu’un client tente d’accéder à une ressource sur un serveur distant.

Tout d’abord, le client va emettre une requête HTTP, cette requête va contenir plusieurs informations tels que l’uri demandé, le User-Agent, etc.

GET http://localhost/GZIPTest/ HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: localhost

Parmi ces informations, il y a un header HTTP nommé Accept-Encoding. Cette valeur indique au serveur quelles sont les formats de fichier que le client est capable de lire. Dans l’exemple ci-dessus, on voit que le client est capable de lire du gzip et du deflate.

Dans ce cas, lorsque le serveur va renvoyer la réponse, il va renvoyer différentes en tête HTTP puis le contenu de la réponse gzippé. Parmi les en-têtes HTTP renvoyés, l’entête Content-Encoding indiquant le format de la réponse.

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Tue, 31 Jan 2012 13:56:08 GMT
Content-Length: 279

Avoir une réponse compressée permet de grandement diminuer la taille des échanges. Si les clients le supportent, il est fortement recommandé de toujours envoyer une réponse gzipée.

Mais comment activer la compression GZIP avec IIS ?

La compression gzip est une fonctionnalité de IIS7 mais n’est pas installé par défaut. Vous pouvez l’installer soit en modifiant l’installation de IIS7 par le server manager, soit en utilisant WebPI.

image

Il existe 2 fonctionnalités distinctes : la compression statique et la compression dynamique. La compression statique permet de compresser les fichiers statiques tels que les .css, .js, etc. alors que la compression dynamique permet de compresser les fichiers dynamiques tels que les fichiers .aspx, etc.

Après avoir installé ces modules, il est ensuite nécessaire de les activer. Dans la console d’administration IIS, une “feature” compression est présente. Lorsque l’on ouvre cette feature, on peut activer ou non la compression statique et/ou dynamique.

image

image

Il existe évidemment des différences entre les 2 modes.

La compression statique est moins couteuse que la compression dynamique, elle est faite qu’une seule fois puis le résultat de la compression est mise en cache. Par défaut, le cache des fichiers compressé se trouvent dans %SystemDrive%\inetpub\temp\IIS Temporary Compressed Files. Si vous avez un grand nombre de fichier et ou si vous avez un espace disque faible, il est recommandé de déplacer ce dossier. Pour cela, vous pouvez le configurer via l’attribut directory de la section system.WebServer/httpCompression.

De plus, par défaut, IIS limite la taille du dossier de cache à 100Mo par pool d’application. L’attribut maxDiskSpaceUsage permet de modifier cette limite, la valeur s’exprime en Mo, il est également possible de désactiver cette limite en mettant l’attribut doDiskSpaceLimiting à false (ce que je ne recommande pas).

<configuration>
  <system.WebServer>
    <httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files" maxDiskSpaceUsage="100" 
doDiskSpaceLimiting="true"
>

Les pages dynamiques étant théoriquement unique, il n’est pas possible de mettre en cache le résultat de la compression, les réponses sont donc compressées à la volée, ce qui peut consommer beaucoup de CPU.

Il existe une sécurité au niveau de IIS permettant de désactiver la compression GZIP en cas de forte charge, cela permet à IIS de répondre à plus de requête tout en étant dans un mode dégradé. Par défaut, pour la compression dynamique son fonctionnement est le suivant : si le pourcentage d’utilisation du CPU moyen sur 30 secondes est supérieur à 90, alors IIS désactivera la compression gzip ; si cette valeur moyenne redescend en dessous de 50, alors IIS réactivera la compression. Il existe le même mécanisme pour la compression statique, cette sécurité est désactivée par défaut.

Ces pourcentages se configurent grace aux attributs dynamicCompressionDisableCpuUsage et dynamicCompressionEnableCpuUsage pour la compression dynamiques et les attributs staticCompressionDisableCpuUsage et staticCompressionEnableCpuUsage pour la compression statique. Il est également possible de désactiver cette sécurité en spécifiant les attributs xxxCompressionDisableCpuUsage à 100.

<configuration>
  <system.WebServer>
    <httpCompression dynamicCompressionDisableCpuUsage="90" dynamicCompressionEnableCpuUsage="50" 
staticCompressionDisableCpuUsage="100" staticCompressionEnableCpuUsage="50"


doDiskSpaceLimiting="true"
>

D’autres paramètres existent et sont listés sur cette page : httpCompression Element [IIS 7 Settings Schema] [MSDN]

Personnellement, il m’arrive de modifier la valeur de dynamicCompressionEnableCpuUsage pour la mettre à 85. En effet, il est possible que certains serveur soit fortement sollicités et dépassent la moyenne de 90% puis reste autour de 60% d’utilisation.

Et vous, avez-vous déjà modifié ces paramètres ?

Posted: mardi 31 janvier 2012 15:52 par cyril
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

JeremyJeanson a dit :

Merci pour ce retour sur la compression.

je l'utilise (quand j'ai accès au serveur) mais je n'ai jamais touché aux settings liés au CPU. Je ne savais pas si ils étaient fiables ;)

# février 2, 2012 09:08
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- SharePoint : Bug sur la gestion des permissions et la synchronisation Office par Blog Technique de Romelard Fabrice le 07-10-2014, 11:35

- SharePoint 2007 : La gestion des permissions pour les Workflows par Blog Technique de Romelard Fabrice le 07-08-2014, 11:27

- TypeMock: mock everything! par Fathi Bellahcene le 07-07-2014, 17:06

- Coding is like Read par Aurélien GALTIER le 07-01-2014, 15:30

- Mes vidéos autour des nouveautés VS 2013 par Fathi Bellahcene le 06-30-2014, 20:52

- Recherche un passionné .NET par Tkfé le 06-16-2014, 12:22

- [CodePlex] Projet KISS Workflow Foundation lancé par Blog de Jérémy Jeanson le 06-08-2014, 22:25

- Etes-vous yOS compatible ? (3/3) : la feuille de route par Le blog de Patrick [MVP SharePoint] le 06-06-2014, 00:30

- [MSDN] Utiliser l'approche Contract First avec Workflow Foundation 4.5 par Blog de Jérémy Jeanson le 06-05-2014, 21:19

- [ #ESPC14 ] TH10 Moving mountains with SharePoint ! par Le blog de Patrick [MVP SharePoint] le 06-01-2014, 11:30