IIS7: Diferencias entre la compresión de contenido estático y dinámico

Question

IIS admite dos tipos de compresión: estática compresión de contenido y compresión de contenido dinámico. De acuerdo con applicationHost.config, son manejados por diferentes módulos: DynamicCompressionModule (compdyn.dll) y StaticCompressionModule (compstat.dll), y están configurados para comprimir diferentes tipos de solicitudes. Además, supongo que la compresión dinámica no almacena en caché las solicitudes comprimidas en lugar de la compresión estática (de forma predeterminada, los archivos comprimidos se guardan en %SystemDrive%\inetpub\temp\IIS Temporary Compressed Files).

Sin embargo, además de esas diferencias obvias, sospecho que hay algo más. Creo que se conectan a la canalización de IIS de una forma ligeramente diferente. ¿Alguien podría tener un poco de más detalles?

La forma en que me enteré fue que I was toying with a custom module for modifying CSS files on fly. Cuando se activó la compresión estática (y se configuró para manejar el conjunto predeterminado de archivos, es decir, también text/css), en la solicitud en caché, mi módulo personalizado recibió el contenido ya comprimido. Cuando moví text/css a la lista de solicitud comprimida dinámicamente, todo comenzó a funcionar. Pero me gustaría tener una prueba más sólida de que realmente es la forma correcta de hacerlo. ¿Hay algunas otras consecuencias/problemas conocidos?

Actualización: Creo que puedo tener una teoría de por qué está sucediendo. Puede que no sea 100% correcto, pero al menos puede explicar el comportamiento observado. Creo que el módulo de compresión estática se registra a los siguientes eventos (entre algunos otros):

RQ_MAP_REQUEST_HANDLER 
RQ_EXECUTE_REQUEST_HANDLER 

Luego, cuando se sirve una solicitud de un archivo estático, el módulo de compresión estática en OnMapRequestHandler comprueba si el archivo ha sido comprimido antes y si el archivo real no ha sido cambiado. Si es así, volverá a mapear la solicitud a sí mismo (devolviendo la redirección apropiada usando IMapHandlerProvider). Cuando más tarde sirva la respuesta en OnExecuteRequestHandler, envía el archivo comprimido. Si, por otro lado, el archivo no se ha comprimido antes o si ha cambiado, no realiza la redirección de asignación y deja que el módulo de contenido estático atienda la solicitud y luego, en OnPostExecuteRequestHandler, comprime el contenido (y actualiza su caché) . Como mencioné anteriormente, no estoy diciendo que esto sea exactamente lo que está sucediendo (no conozco el código fuente), puede ser solo una aproximación. Además, el módulo de compresión dinámica probablemente no haga nada de esto. Simplemente comprime las respuestas salientes a veces después de RQ_EXECUTE_REQUEST_HANDLER.

Answer 1

Su pregunta no está del todo clara, entonces responderé a una pregunta y espero que sea su pregunta.

El objetivo de la compresión estática es comprimir los archivos que de otro modo serían servidos directamente desde el disco duro (Css/images/javascript) y comprimir cada archivo una vez y guardar el archivo comprimido en el disco. Esto permite una muy rápida y muy económica porción de contenido comprimido para archivos estáticos que cambian con poca frecuencia. Es una recomendación bastante segura decir que la mayoría del sitio web debe tener habilitada la compresión estática.

La intención de la compresión dinámica es comprimir las respuestas dinámicas de los módulos ISS (asp, asp.net, php, etc.). Como esta respuesta puede ser diferente para cada solicitud, la salida comprimida no se puede almacenar en caché. Esta característica es nueva de IIS6, aunque el efecto se ha podido lograr en algunos entornos, p. implementando un HttpFilter en ASP.Net. Como cada solicitud debe comprimirse sobre la marcha, esto requiere mucha más CPU que compresión estática. Entonces, si un servidor está vinculado a la CPU, esta puede no ser una buena opción.La mayoría de los sitios están enlazados a la red o a la base de datos, por lo que a menudo es una buena idea.

Por lo tanto, la dinámica y la estática se refieren al contenido y afectan a las estrategias que se pueden usar.

algunas referencias

• http://www.iis.net/overview/DynamicCachingAndCompression
• http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/92f627a8-4ec3-480c-b0be-59a561091597.mspx?mfr=true

Answer 2

experimentar con función de compresión de IIS, me pareció que el módulo dinámico y el módulo estático no están tan atados a contenido dinámico o estático (especialmente para el módulo dinámico).

Activar la compresión para text/html (o text/*) tipo mime en el módulo dinámico, y no en el módulo estático. Acceda a un archivo .html. Comprueba la respuesta http en el navegador: está comprimida. (Probado en IIS 7.5 en 2008R2 server.)

Parece que el módulo de compresión dinámica no está limitado a contenido dinámico. Tiene contenido estático comprimido siempre que coincida con su lista de tipos mime y no esté ya comprimido. Por lo tanto, considero que debe entenderse como un "módulo de compresión" dinámico, en el sentido en que se desencadena en cada respuesta (en función de sus criterios de tipo MIME, y en el encabezado de solicitud accept-encoding).

Mientras que el módulo de compresión estático se dispara un poco como un proceso en segundo plano que trabaja en los archivos, y comienza a dar salida comprimida solo una vez que los tiene en su caché. Dado que el módulo de compresión estática ejecuta el farer en la pila de módulos, maneja la respuesta antes del módulo de compresión dinámica, por lo que tiene prioridad sobre la dinámica si tiene salida comprimida para servir.

Así que para su caso de uso específico, debe desactivar el módulo de compresión estática en text/css tipo MIME (cuidado de eliminar text\* también si está presente) con el fin de evitar problemas de almacenamiento en caché de derrotar a su CSS personalizado módulo de parcheo.

También puede activar la compresión de text/css en el módulo de compresión dinámica para reemplazar el módulo de compresión estática en este caso. Pero, por supuesto, no aprovechará la capacidad de caché del módulo de compresión estática.

Desafortunadamente, no he encontrado ninguna documentación para respaldar las declaraciones anteriores.

Otra opción podría ser tratar de alterar el orden de ejecución del módulo IIS. Tendría que eliminarlos todos en la configuración de su sitio, luego volver a agregarlos, insertando su módulo personalizado tal vez antes de la compresión estática. Pero este podría ser un camino complicado.