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

Question

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

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

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

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

RQ_MAP_REQUEST_HANDLER
RQ_EXECUTE_REQUEST_HANDLER

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

Answer 1

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

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

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

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

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

• 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

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

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

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

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

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

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

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