IIS7: Различия между сжатием статического и динамического содержимого

IIS поддерживает два типа сжатия: статическое сжатие содержимого и динамическое сжатие содержимого. Согласно applicationHost.config, они обрабатываются различными модулями: DynamicCompressionModule (compdyn.dll) и StaticCompressionModule (compstat.dll), и они настроены на сжатие различных типов запросов > . Кроме того, я предполагаю, что динамическое сжатие не кэширует сжатые запросы, а не статическое сжатие (по умолчанию сжатые файлы сохраняются в %SystemDrive%\inetpub\temp\IIS Temporary Compressed Files).

Однако, помимо этих очевидных различий, я подозреваю, что есть что-то еще. Я думаю, что они подключаются к конвейеру IIS несколько иначе. Будет ли кто-нибудь внутри в некоторых подробностях?

Я узнал, что я играл с настраиваемым модулем для изменения файлов CSS на лету. Когда статическое сжатие было включено (и настроено для обработки набора файлов по умолчанию, то есть также text/css), в кэшированном запросе моему пользовательскому модулю был отправлен уже обработанный gzipped контент. Когда я переместил текст /css в список динамически сжатого запроса, все это начало работать. Но я хотел бы получить более убедительное доказательство того, что это действительно правильный способ сделать это. Существуют ли другие известные последствия/проблемы?

Обновление: Я думаю, у меня может быть теория о том, почему это происходит. Это может быть не на 100% правильным, но, по крайней мере, это может объяснить наблюдаемое поведение. Я думаю, что статический модуль сжатия регистрируется в следующих событиях (среди других):

RQ_MAP_REQUEST_HANDLER
RQ_EXECUTE_REQUEST_HANDLER

Затем, когда подан запрос на статический файл, статический модуль сжатия в OnMapRequestHandler проверяет, был ли файл сжат раньше и фактический файл не был изменен. Если это так, он перекроет запрос самому себе (возвращая соответствующее перенаправление с помощью IMapHandlerProvider). Когда он позже фактически отвечает за ответ в OnExecuteRequestHandler, он отправляет сжатый файл. Если, с другой стороны, файл не был сжат раньше или если он был изменен, он не перенаправляет отображение и позволяет статическому модулю содержимого обслуживать запрос, а затем в OnPostExecuteRequestHandler сжимает содержимое (и обновляет его кеш). Как уже упоминалось выше, я не говорю, что это именно то, что происходит (я не знаю исходного кода), это может быть только приближение. Кроме того, модуль динамического сжатия, скорее всего, не сделает этого. Он просто сжимает исходящие ответы иногда после RQ_EXECUTE_REQUEST_HANDLER.

Ответ 1

Ваш вопрос не совсем ясен, поэтому я отвечу на вопрос и надеюсь, что это ваш вопрос.

Цель статического сжатия - сжать файлы, которые в противном случае были бы переданы непосредственно с жесткого диска (Css/images/javascript), и как таковая он сжимает каждый файл один раз и сохраняет сжатый файл на диск. Это позволяет очень быстро и очень дешево обслуживать сжатый контент для статических файлов, которые изменяются нечасто. Это довольно безопасная рекомендация сказать, что на большинстве веб-сайтов должно быть включено статическое сжатие.

Цель динамического сжатия - сжать динамические ответы от модулей ISS (asp, asp.net, php и т.д.). Поскольку этот ответ может отличаться для каждого запроса, сжатый вывод не может быть кэширован. Эта функция нова от IIS6, хотя эффект был достигнут в некоторых средах, например. путем реализации HttpFilter в ASP.Net. Поскольку каждый запрос нужно сжимать "на лету", это гораздо более интенсивное процессорное, чем статическое сжатие. Поэтому, если сервер связан с ЦП, это может быть не очень хорошим вариантом. Большинство сайтов связаны с сетью и/или базой данных, поэтому часто это хорошая идея.

Таким образом, динамические и статические относятся к контенту и влияют на то, какие стратегии можно использовать.

Некоторые ссылки

Ответ 2

Экспериментируя с функцией сжатия IIS, мне показалось, что динамический модуль и статический модуль не так привязаны к динамическому или статическому контенту (особенно для динамического модуля).

Активировать сжатие для тима text/html (или text/*) mime на динамическом модуле, а не на статическом модуле. Доступ к файлу .html. Проверяет ответ HTTP в браузере: он сжимается. (Проверено на IIS 7.5 на сервере 2008R2.)

Похоже, динамический модуль сжатия не ограничивается динамическим контентом. Он создает сжатый статический контент, предоставляя ему соответствие его списку типов mime и уже не сжимается. Поэтому я считаю, что это следует понимать как динамический "модуль сжатия" в том смысле, что он срабатывает при каждом ответе (на основе его критериев типа mime и заголовка запроса accept-encoding).

Пока статический модуль сжатия запускается немного как фоновый процесс, работающий с файлами, и начинает подавать сжатый вывод только после того, как он имеет их в кеше. Поскольку статический компрессионный модуль выполняет намного больше в стеке модулей, он обрабатывает ответ до модуля динамической компрессии и поэтому имеет приоритет над динамическим, если он имеет сжатый вывод для обслуживания.

Итак, для вашего конкретного случая использования вы должны отключить статический модуль сжатия в типе text/css mime (остерегайтесь удаления text\*, если он есть), чтобы избежать проблем с кешированием, поражающих ваш пользовательский модуль исправления CSS.

Вы можете дополнительно активировать сжатие text/css в динамическом модуле сжатия для замены статического модуля сжатия на этот случай. Но, конечно же, он не будет использовать способность кэширования статического сжатия.

К сожалению, я не нашел никакой документации для резервного копирования выше инструкций.

Другой вариант - это попытка изменить порядок выполнения модуля IIS. Вам нужно будет удалить их все в конфигурации вашего сайта, а затем повторно добавить их, добавив свой настраиваемый модуль, возможно, перед статическим сжатием. Но это может быть сложным путем.