2009-04-24 34 views
68

He instalado la compresión estática y dinámica para IIS7, así como la configuración de los dos valores web.config en mi aplicación Virtual Folder nivel. Según lo entiendo, no necesito habilitar la compresión en el servidor, ni en el nivel del sitio, y puedo administrarlo por carpeta usando mi archivo web.config.¿Cómo puedo hacer que funcione la compresión gzip en IIS7?

Tengo dos configuraciones en mi archivo .config que he configurar para personalizar gzip para mi aplicación:

<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" /> 

Sin embargo, cuando ejecuto la aplicación, puedo ver claramente que gzip no se utiliza, porque mi los tamaños de página son iguales. También estoy usando YSlow para Firefox, que también confirma que mis páginas no están siendo cargadas.

¿Qué me falta aquí? En IIS6 fue una simple cuestión de especificar los tipos de archivos y establecer el nivel de compresión entre 0-10. No veo la necesidad documentada de especificar los tipos de archivos o el nivel de compresión, ya que los valores predeterminados parecen abarcar los tipos de archivos, y no veo el nivel en ningún lado.

+0

0 deposito voto \t Por favor, echar un vistazo a este post: stackoverflow.com/a/7634875/1131855 yo no era capaz de editar applicationHost.config a través de Notepad ++. Este enlace sugirió un comando de consola que funcionó para mí –

Respuesta

61

Hubo un hilo en forums.iis.net sobre esto durante el IIS 7 beta. Resultó que el tipo no tenía los módulos instalados, pero parece que lo ha descartado de su frase inicial.

El consejo clave de Microsoft para él fue habilitar el seguimiento de solicitudes fallidas para descubrir qué estaba fallando. Esta es posiblemente una de las características menos apreciadas de IIS7, pero sin duda una de las más poderosas.

  • Abra el Administrador de IIS.
  • Vaya a su sitio, y en el panel de acciones (el extremo derecho), haga clic en 'Seguimiento de solicitud fallida ...' en la sección 'Configurar'.
  • Haga clic en "habilitar".
  • Luego, en la vista de características, haga clic en 'Reglas de seguimiento de solicitud fallidas'. Haga clic en agregar, luego, ingrese 200 para el código de estado, luego, haga clic en finalizar.

Si no ve "Seguimiento de solicitudes Error" en el panel de acciones, tendrá que agregar la función de servidor - ya sea mediante el asistente "Agregar servicios de función" (Salud y Diagnóstico \ Tracing) o a través del instalador de plataforma web (Products \ Server \ IIS: Tracing) y luego cierre y vuelva a abrir el Administrador de IIS.

A continuación, vuelva a ejecutar su prueba. Esto generará algo de información de registro para que podamos examinar.

Busque en c: \ inetpub \ logs \ FailedReqLogFiles \ w3svcx. Verá un grupo de archivos llamados fr000xx.xml. Abre cualquiera de ellos en tu navegador. (Por cierto, si copia estos archivos en cualquier lugar, asegúrese de que freb.xsl esté allí. Además, no elimine freb.xsl; si lo hace, simplemente elimine todo el directorio o cópielo desde otra ubicación, ya que IIS solo crea una vez por carpeta.)

Haga clic en la pestaña 'detalles de la solicitud' y seleccione 'completar seguimiento de solicitud'. Busque en la página 'comprimir', debería encontrarlo en varias áreas; una vez para el contenido estático y una para el contenido dinámico.

Si no encuentra ninguno de ellos, IIS no está configurado correctamente.Si los encuentra, debería verlos seguidos por un compression_success y un compression_do. El éxito es auto explicativo; el 'do' indica lo que hizo - en mi caso, mostró "OriginalSize 1462784 Comprimido Tamaño 179482"

Dado que el suyo no funciona, con suerte verá algo diferente que le ayuda a resolver el problema.

Asegúrese de desactivarlo cuando haya terminado deshabilitando el seguimiento de solicitudes fallidas en el panel de acciones de su sitio web.

+13

esto ayudó! Resultó que nuestro culpable era dynamicCompressionDisableCpuUsage - de forma predeterminada, si tocas el 90% de compresión dinámica está deshabilitada y no se volverá a habilitar hasta que la CPU vuelva a bajar a dynamicCompressionEnableCpuUsage que por defecto es 50% (!!) –

+4

Tenga en cuenta que necesita asegúrese de que el seguimiento esté instalado: http://www.iis.net/ConfigReference/system.webServer/tracing/traceFailedRequests – mhenry1384

+0

@JohnW esto ayudó hasta cierto punto. Pude obtener STATIC_COMPRESSION_NOT_SUCCESS a STATIC_COMPRESSION_SUCCESS cambiando la Ignore Hit Frequency en la applicationHost.config directamente pero aún no devuelve los datos comprimidos al navegador. Aquí tengo un hilo separado: http: // stackoverflow.com/q/38250376/392591 – Jacques

3

activar la compresión estática. compresión dinámica es para páginas dinámicas como ASP, PHP, aspx, etc.

Aquí hay un enlace a la IIS config reference for compression:

+0

No veo dónde necesitaría hacer eso para IIS7. Lo veo en IIS6, pero no en 7. – Russ

+1

, lo puede encontrar en el Administrador IIS (inetmgr) en la sección IIS. abra el elemento "Compresión" y marque la casilla de verificación "Habilitar la compresión de contenido estático". –

+0

agregó un enlace a la referencia de configuración de IIS. –

5

En la sección system.webServer de su archivo Web.config, agregue las siguientes líneas:

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

El esquema de compresión en IIS7 está activado por defecto, pero se asigna un solo tipo MIME que Javascript esté comprimido, application/x-javascript. Al agregar la línea anterior, se le indica a IIS que proporcione todos los archivos .js que mime, lo que a su vez hace que la compresión funcione.

+0

Lo intenté y no funcionó :( – vtortola

+0

Encontré que era al revés: el servidor enviaba JS como 'application/x-javascript', pero estaba comprimiendo' application/javascript' –

26

Hemos tenido un problema similar y resulta que IIS7 hace algo de estrangulación basada CPU dinámica aquí ..

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

dynamicCompressionDisableCpuUsage

atributo uint opcional.

Especifica el porcentaje de utilización de CPU en el que se desactivará la compresión dinámica.

Nota: Este atributo actúa como un límite de CPU superior en el que la compresión dinámica está desactivada. Cuando la utilización de la CPU cae por debajo del valor especificado en el atributo dynamicCompressionEnableCpuUsage, la compresión dinámica se volverá a habilitar.

El valor por defecto es 90.


dynamicCompressionEnableCpuUsage

atributo uint opcional.

Especifica el porcentaje de utilización de CPU por debajo del cual se habilitará la compresión dinámica. El valor debe estar entre 0 y 100. La utilización promedio de la CPU se calcula cada 30 segundos.

Nota: Este atributo actúa como un límite de CPU inferior debajo del cual se activa la compresión dinámica. Cuando la utilización de la CPU aumenta por encima del valor especificado en el atributo dynamicCompressionDisableCpuUsage, la compresión dinámica se desactivará.

El valor por defecto es 50.

Nota los valores por defecto - si su IIS7 golpea el 90% de uso de CPU, se desactivar todo el contenido dinámico gzipped hasta el uso de la CPU se sumerge de nuevo por debajo del 50%!

Además, algunas grandes recomendaciones y puntos de referencia aquí sobre el costo real de CPU de GZIP.

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

larga historia corta, a menos que regularmente tiene páginas dinámicas muy por encima de 200kb, es un no-tema.

5

Resolví mi problema instalando la compresión dinámica en Agregar o quitar programas.

20

Tras el excelente consejo de johnw, yo también habilitado el registro para encontrar al culpable, aunque el motivo del fallo resultó ser diferente:

STATIC_COMPRESSION_NOT_SUCCESS 
Reason 14 
Reason NOT_FREQUENTLY_HIT 

En resumen, parece que si no lo hace Si aparece en la página con bastante frecuencia, IIS7 no lo considerará digno de compresión, lo cual me parece un poco extraño. No obstante, tiene sentido en este caso porque solo estaba tratando de probarlo en una máquina local.

De acuerdo con this page, el valor predeterminado parece ser que una página tiene que ser golpeada 2 veces en 10 segundos para ser un "golpe frecuente". Si realmente lo desea, puede anular el valor predeterminado en applicationHost.config (% systemroot% \ Windows \ System32 \ inetsrv \ config). Al menos para mí es un atributo bloqueado, por lo que no podrás anularlo en tu propio web.config.

<serverRuntime frequentHitThreshold="1" /> 

Además, ahora cuenta que ya tenía SO esta respuesta aquí: In IIS7, gzipped files do not stay that way.

0

Para mí resultó ser el ajuste

noCompressionForProxies 

ya que estamos en un proxy aquí ... tomó a mí mismo fuera de proxy y listo, compresión.

Cuestiones relacionadas