web-dev-qa-db-fra.com

Comment faire fonctionner la compression gzip dans IIS7?

J'ai installé la compression statique et dynamique pour IIS7, ainsi que la définition des deux valeurs web.config au niveau de mon application Virtual Folder. Si je comprends bien, je n'ai plus besoin d'activer la compression au niveau du serveur ou du site, et je peux la gérer dossier par dossier à l'aide de mon fichier web.config.

Mon fichier .config contient deux paramètres que j'ai définis pour personnaliser gzip pour mon application:

<httpCompression dynamicCompressionDisableCpuUsage="90"
    dynamicCompressionEnableCpuUsage="0">
  <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" />
  <dynamicTypes>
    <remove mimeType="*/*"/>
    <add mimeType="*/*" enabled="true" />
  </dynamicTypes>
</httpCompression>
<urlCompression doDynamicCompression="true"
    dynamicCompressionBeforeCache="true" />

Cependant, lorsque j'exécute l'application, je vois clairement que gzip n'est pas utilisé, car la taille de mes pages est identique. J'utilise également YSlow pour FireFox, ce qui confirme également que mes pages ne sont pas gzipées.

Qu'est-ce que j'oublie ici? Dans IIS6, il suffisait de spécifier les types de fichiers et de définir le niveau de compression entre 0 et 10. Je ne vois pas la nécessité documentée de spécifier les types de fichiers ou le niveau de compression, car les valeurs par défaut semblent couvrir les types de fichiers, et je ne vois le niveau nulle part.

asp.net.net-3.5iis-7compressiongzip
68
Russ

Il y avait un fil de discussion sur forums.iis.net à ce sujet pendant la version bêta de iis 7. Il s'est avéré que le gars n'avait pas installé les modules, mais il semblerait que vous l'ayez exclu de votre phrase d'ouverture.

Le conseil clé de Microsoft pour lui consistait à activer le suivi des demandes infructueuses pour déterminer ce qui n'allait pas. C’est peut-être l’une des fonctionnalités les plus sous-estimées d’IIS7, mais certainement l’une des plus puissantes. 

  • Ouvrez le gestionnaire IIS.
  • Accédez à votre site et, dans le volet Actions (à l'extrême droite), cliquez sur "Suivi des demandes ayant échoué ..." dans la section "Configurer".
  • Cliquez sur "Activer". 
  • Ensuite, dans la vue des fonctionnalités, cliquez sur "Règles de suivi des demandes ayant échoué". Cliquez sur Ajouter, ensuite, entrez 200 pour le code d'état, puis cliquez sur Terminer.

Si vous ne voyez pas "Suivi des demandes ayant échoué" dans le volet Actions, vous devez ajouter la fonctionnalité au serveur - à l'aide de l'assistant "Ajouter des services de rôle" (Health and Diagnostics\Tracing) ou via Web Platform Installer. (Products\Server\IIS: Tracing), puis fermez et rouvrez le Gestionnaire IIS.

Ensuite, relancez votre test. Cela générera des informations de journal que nous pourrons examiner.

Recherchez dans c:\inetpub\logs\FailedReqLogFiles\w3svcx. Vous verrez un tas de fichiers nommés fr000xx.xml. Ouvrez l'un d'entre eux dans votre navigateur. (Au fait, si vous copiez ces fichiers n’importe où, assurez-vous que freb.xsl est là. En outre, ne supprimez pas freb.xsl. Si vous le faites, supprimez tout le répertoire ou copiez-le depuis un autre emplacement, comme IIS ne le crée qu'une fois par dossier.)

Cliquez sur l'onglet "Détails de la demande" et sélectionnez "Suivi complet de la demande". Cherchez dans la page 'compresser' - vous devriez la trouver dans plusieurs endroits; une fois pour le contenu statique et une fois pour le contenu dynamique. 

Si vous ne trouvez aucun d'entre eux, IIS n'est pas configuré correctement. Si vous les trouvez, vous devriez les voir suivis d'un compression_success et d'un compression_do. Le succès est explicite. le 'do' indique ce qu'il a fait - dans mon cas, il a montré "OriginalSize 1462784 CompressedSize 179482"

Puisque le vôtre ne fonctionne pas, j'espère que vous verrez quelque chose de différent qui vous aidera à résoudre le problème.

Assurez-vous de désactiver cette option lorsque vous avez terminé en désactivant le suivi des demandes ayant échoué dans le volet Actions de votre site Web.

62
JohnW

Nous avons eu un problème similaire et il s’est avéré que IIS7 effectuait des limitations dynamiques basées sur le processeur ici ..

http://www.iis.net/ConfigReference/system.webServer/httpCompression

dynamicCompressionDisableCpuUsage

Attribut facultatif uint.

Spécifie le pourcentage d'utilisation du processeur pour lequel la compression dynamique sera désactivée.

Remarque: cet attribut agit comme une limite supérieure de l'UC à laquelle la compression dynamique est désactivée. Lorsque l'utilisation de l'UC devient inférieure à la valeur spécifiée dans l'attribut dynamicCompressionEnableCpuUsage, la compression dynamique est réactivée.

La valeur par défaut est 90.

dynamicCompressionEnableCpuUsage

Attribut facultatif uint.

Spécifie le pourcentage d'utilisation du processeur en dessous duquel la compression dynamique sera activée. La valeur doit être comprise entre 0 et 100. L'utilisation moyenne de la CPU est calculée toutes les 30 secondes.

Remarque: Cet attribut agit comme une limite inférieure du processeur en dessous de laquelle la compression dynamique est activée. Lorsque l'utilisation de l'UC dépasse la valeur spécifiée dans l'attribut dynamicCompressionDisableCpuUsage, la compression dynamique est désactivée.

La valeur par défaut est 50.

Notez les valeurs par défaut - si votre IIS7 atteint 90% d'utilisation du processeur, il restera désactivera tout le contenu gzippé dynamique jusqu'à ce que l'utilisation du processeur repasse sous 50%!

En outre, voici quelques recommandations et points de repère intéressants sur le coût réel du processeur de GZIP.

http://weblogs.asp.net/owscott/archive/2009/02/22/iis-7-compression-good-bad-how-much.aspx

En bref, à moins que vous n'ayez régulièrement des pages dynamiques dépassant les 200 ko, ce n'est pas un problème.

27
Jeff Atwood

À la suite des excellents conseils de JohnW, j’ai aussi permis à l’enregistrement de trouver le coupable, bien que la raison de l’échec se soit avérée différente:

STATIC_COMPRESSION_NOT_SUCCESS 
Reason 14 
Reason NOT_FREQUENTLY_HIT

En bref, il semble que si vous ne cliquez pas assez souvent sur la page, IIS7 ne la jugera pas digne d'être compressée, ce qui me semble un peu étrange. Néanmoins, cela a du sens dans ce cas parce que j’essayais simplement de le tester sur une machine locale.

Selon cette page , le défaut semble être qu'une page doit être consultée 2 fois en 10 secondes pour être un "hit fréquent". Si vous le souhaitez vraiment, vous pouvez remplacer la valeur par défaut dans applicationHost.config (% systemroot%\Windows\System32\inetsrv\config). Au moins pour moi, c'est un attribut verrouillé, vous ne pourrez donc pas le remplacer dans votre propre web.config.

<serverRuntime frequentHitThreshold="1" />

En outre, je remarque maintenant que SO avait déjà cette réponse ici: Dans IIS7, les fichiers compressés ne restent pas ainsi .

21
Gavin

J'ai résolu mon problème en installant une compression dynamique dans Ajout/Suppression de programmes.

5
Eduardo

Dans la section system.webServer de votre fichier Web.config, ajoutez les lignes suivantes:

<remove fileExtension=".js" />  
<mimeMap fileExtension=".js" mimeType="application/x-javascript" />

Le schéma de compression dans IIS7 est activé par défaut, mais il mappe un seul type mime javascript à compresser, application/x-javascript. L'ajout de la ligne ci-dessus indique à IIS de donner à tous vos fichiers .js ce type mime, ce qui rend la compression opérationnelle.

5
jvenema

activer la compression statique. la compression dynamique est destinée aux pages dynamiques comme asp, php, aspx, etc.

Voici un lien vers la référence de configuration IIS pour la compression : 

3
Darren Kopp

Pour moi, il s’est avéré être le cadre

noCompressionForProxies

comme nous sommes sur un proxy ici ... me suis retiré du proxy et le tour est joué, la compression.

0
µBio