Comment faire fonctionner la compression gzip dans IIS7?

Question

J'ai installé Statique et dynamique de compression pour IIS7, ainsi que de mettre les deux web.config valeurs à ma demande Virtual Folder . Si je comprends bien, je n'ai pas besoin d'activer la compression sur le serveur, ou au niveau du site, et de plus, je peux le gérer sur une base par dossier à l'aide de mon web.fichier de configuration.

J'ai deux paramètres dans mon .config le fichier que j'ai mis à 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 je lance l'application, je peux voir clairement que gzip n'est pas utilisé, parce que ma page les tailles sont les mêmes. Je suis également à l'aide de YSlow pour FireFox, qui confirme aussi que mes pages ne sont pas gziped.

Ce qui me manque ici? Dans IIS6 c'était une simple question de spécifier les types de fichiers, et le réglage du niveau de compression entre 0 et 10. Je ne vois pas la nécessité documenté pour spécifier les types de fichiers ou le niveau de compression, puisque les valeurs par défaut semblent couvrir les types de fichiers, et je ne suis pas de voir le niveau de n'importe où.

Answer 1

Il y avait un thread sur forums.iis.net à ce sujet lors de l'iis 7 bêta. S'est avéré que le gars n'avait pas les modules installés, mais il semble que vous avez jugé que votre phrase d'ouverture.

Microsoft clé de conseils pour lui était de permettre suivi des demandes ayant échoué à trouver ce qui n'allait pas. C'est peut-être l'un des plus sous-estimé les caractéristiques de IIS7, mais certainement l'un des plus puissants.

• Ouvrez le Gestionnaire des services IIS.
• Allez sur votre site, et sur le volet actions (très à droite), cliquez sur "suivi des demandes ayant Échoué... "sous " Configurer".
• Cliquez sur "activer".
• Puis, à la vue des fonctionnalités, cliquez sur " suivi des demandes ayant Échoué de règles. Cliquez sur ajouter, ensuite, entrez 200 du code d'état suivant, cliquez sur terminer.

Si vous ne voyez pas "suivi des demandes ayant Échoué" dans le volet actions, vous aurez besoin d'ajouter la fonctionnalité du serveur - soit en cliquant sur "Ajouter des Services de Rôle" assistant (état de Santé et Diagnostics\Tracing) ou via le Web Platform Installer (Produits\Serveur\IIS: Traçage), puis fermez et ré-ouvrez le Gestionnaire des services IIS.

Ensuite, exécutez à nouveau le test. Cela va générer quelques info connectez-vous pour nous examiner.

Regarder dans c:\inetpub\logs\FailedReqLogFiles\w3svcx. Vous verrez un tas de fichiers nommés fr000xx.xml. Ouvrir dans votre navigateur. (En passant, si vous copiez ces fichiers n'importe où, assurez-vous que freb.xsl est là. Aussi, ne pas supprimer freb.xsl - si vous le faites, il suffit de supprimer le répertoire entier ou de le copier à partir d'un autre emplacement, comme IIS crée seulement une fois par dossier).

Cliquez sur le bouton 'détails de la demande de l'onglet et sélectionnez "demande complète de trace". Recherche la page de "comprimer" - vous devriez le trouver dans plusieurs domaines; la fois pour le contenu statique, et une fois pour le contenu dynamique.

Si vous ne trouvez pas l'un d'eux, IIS n'est pas correctement configuré. Si vous les trouvez, vous devriez les voir suivie par un compression_success et un compression_do. Le succès est auto-explicatif; le "faire", indique ce qu'il a fait, dans mon cas, il a montré "OriginalSize 1462784 CompressedSize 179482"

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

Assurez-vous que vous désactivez cette fonction lorsque vous avez terminé par la désactivation du suivi des demandes ayant échoué dans le volet actions pour votre site web.

Answer 2

Nous avons eu un problème similaire et il s'avère que IIS7 fait de la dynamique du PROCESSEUR en fonction de la limitation ici..

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

dynamicCompressionDisableCpuUsage

En option uint attribut.

Spécifie le pourcentage d'utilisation du PROCESSEUR au cours de laquelle la compression dynamique sera désactivé.

Remarque: Cet attribut agit comme un upper CPU limite à partir de laquelle la compression dynamique est désactivée. Lorsque le PROCESSEUR tombe en dessous de la valeur spécifiée dans le dynamicCompressionEnableCpuUsage attribut, la compression dynamique sera réactivé.

La valeur par défaut est de 90.

---

dynamicCompressionEnableCpuUsage

En option uint attribut.

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

Remarque: Cet attribut agit comme un inférieur CPU limite en dessous de laquelle la compression dynamique est activée. Lors de l'utilisation de l'UC monte au-dessus de la valeur indiquée dans la dynamicCompressionDisableCpuUsage attribut, la compression dynamique sera désactivé.

La valeur par défaut est 50.

Remarque les valeurs par défaut -- si votre IIS7 hits 90% d'utilisation du PROCESSEUR, il va désactiver toutes les dynamiques au format gzip contenu jusqu'à ce que l'utilisation CPU creux de retour en dessous de 50%!

Également, quelques grands recommandations et repères ici sur le véritable coût de l'UC de GZIP.

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

Longue histoire courte, sauf si vous avez régulièrement des pages dynamiques, bien au-delà de 200 ko, c'est un non-problème.

Answer 3

En suivant les excellents conseils de JohnW, j'ai aussi activé la journalisation de trouver le coupable, bien que la raison de l'échec s'est avéré être différent:

STATIC_COMPRESSION_NOT_SUCCESS 
Reason 14 
Reason NOT_FREQUENTLY_HIT

C'est un obscur, mais heureusement, j'ai trouvé quelqu'un avec le même problème, et mieux encore, la solution.

En bref, il apparaît que si vous n'avez pas accès à la page assez fréquemment, puis IIS7 sera pas jugé digne de la compression, ce qui semble un peu étrange pour moi. Néanmoins, n'a de sens dans ce cas parce que j'étais juste en train de tester sur une machine locale.

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

<serverRuntime frequentHitThreshold="1" />

Aussi, je remarque maintenant que DONC déjà eu cette réponse ici: http://stackoverflow.com/questions/2203798/in-iis7-gzipped-files-do-not-stay-that-way.

Answer 4

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

Answer 5

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 qu'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 facilite la compression.