Пункт 121. Модуль Apache mod_cache
mod_cache реализует фильтр кэширования контента HTTP, совместимый с RFC 2616
, с поддержкой кэширования согласованных ответов контента, содержащих заголовок Vary.
Кэширование в соответствии с RFC 2616 обеспечивает механизм проверки того, является ли устаревшее или просроченное содержимое все еще свежим, и может обеспечить значительное повышение производительности, когда исходный сервер поддерживает условные запросы , соблюдая заголовок HTTP-запроса If-None-Match. Контент регенерируется с нуля только при изменении контента, а не по истечении срока действия кэшированной записи.
В качестве фильтра mod_cache может размещаться перед содержимым, происходящим из любого обработчика, включая плоские файлы (отправляемые с медленного диска, кэшированные на быстром диске), выходные данные сценария CGI или генератора динамического содержимого или содержимое, проксируемое с другого сервера .
В конфигурации по умолчанию mod_cache фильтр кэширования вставляется как можно дальше в стек фильтров, используя быстрый обработчик для обхода всей обработки каждого запроса при возврате содержимого клиенту. В этом режиме работы mod_cache его можно рассматривать как кеширующий прокси-сервер, прикрепленный к передней части веб-сервера, работающий внутри самого веб-сервера.
Когда быстрый обработчик отключен директивой
CacheQuickHandler , появляется возможность вставить фильтр CACHE в точку стека фильтров, выбранную администратором. Это дает возможность кэшировать содержимое до того, как это содержимое будет персонализировано фильтром
mod_include или, при необходимости, сжато фильтром
mod_deflate .
При нормальной работе mod_cache отвечает и может управляться заголовками Cache-Control и Pragma, отправленными клиентом в запросе или сервером в ответе. В исключительных случаях
mod_cache можно настроить переопределение этих заголовков и принудительное поведение конкретного сайта, однако такое поведение будет ограничено только этим кешем и не повлияет на работу других кешей, которые могут существовать между клиентом и сервером, и в результате не рекомендуется без крайней необходимости.
RFC 2616 позволяет кэшу возвращать устаревшие данные, в то время как существующая устаревшая запись обновляется с исходного сервера, и это поддерживается при mod_cache соответствующей
CacheLock настройке директивы. Такие ответы будут содержать HTTP-заголовок Warning с кодом ответа 110. RFC 2616 также позволяет кэшу возвращать устаревшие данные, когда попытка обновить устаревшие данные возвращает ошибку 500 или выше, и такое поведение по умолчанию поддерживается
mod_cache . Такие ответы будут содержать HTTP-заголовок Warning с кодом ответа 111.
mod_cache требуются услуги одного или нескольких модулей управления хранением. В базовый дистрибутив Apache включены следующие модули управления хранилищем:
-
mod_cache_disk
- Реализует дисковый менеджер хранения. Заголовки и тела хранятся отдельно на диске в структуре каталогов, полученной из хэша md5 кэшированного URL-адреса. Несколько ответов на согласование содержимого могут храниться одновременно, однако кэширование частичного содержимого не поддерживается этим модулем. Инструмент
htcacheclean предоставляется для отображения кэшированных URL-адресов, удаления кэшированных URL-адресов или для поддержания размера дискового кэша в пределах размера и индексов.
-
mod_cache_socache
- Реализует менеджер хранилища на основе кэша общих объектов. Заголовки и тела хранятся вместе под одним ключом на основе URL-адреса кэшируемого ответа. Несколько ответов на согласование содержимого могут храниться одновременно, однако кэширование частичного содержимого не поддерживается этим модулем.
Дополнительные подробности, обсуждение и примеры приведены в Руководстве по кэшированию.
Связанные модули и директивы
Пример конфигурации
Образец apache2.conf
#
# Пример конфигурации кэша
#
Модули LoadModule cache_module/mod_cache.so
<IfModule mod_cache.c>
LoadModule cache_disk_module modules/mod_cache_disk.so
<IfModule mod_cache_disk.c>
CacheRoot "c:/cacheroot"
CacheEnable диск "/"
CacheDirLevels 5
CacheDirLength 3
</ЕслиМодуль>
# При работе в качестве прокси не кэшировать список обновлений безопасности
CacheDisable "http://security.update.server/update-list/"
</ЕслиМодуль>
Избегание Громового Стада
Когда кешированная запись устаревает, mod_cache серверу будет отправлен условный запрос, который, как ожидается, подтвердит, свежа ли кешированная запись, и отправит обновленный объект, если нет.
Между моментом, когда кэшированный объект становится устаревшим, и временем, когда устаревший объект полностью обновляется, существует небольшой, но конечный промежуток времени. На загруженном сервере за это время может поступить значительное количество запросов, что приведет к внезапному и непредсказуемому обрушению огромного количества запросов на серверную часть.
Чтобы держать громыхающее стадо в страхе, CacheLock
директиву можно использовать для определения каталога, в котором создаются блокировки для URL-адресов в полете . Блокировка используется в качестве подсказки
другими запросами, чтобы либо подавить попытку кэширования (кто-то другой пошел, чтобы получить объект), либо указать, что устаревшая запись обновляется (в это время будет возвращено устаревшее содержимое).
Начальное кэширование записи
Когда объект кэшируется в первый раз, для объекта будет создана блокировка до тех пор, пока ответ не будет полностью кэширован. В течение срока действия блокировки кэш подавляет вторую и последующие попытки кэширования одного и того же объекта. Хотя это не сдерживает громоподобное стадо, но останавливает попытки кеша кэшировать один и тот же объект несколько раз одновременно.
Обновление устаревшей записи
Когда сущность достигает своего срока действия и становится устаревшей, для сущности будет создана блокировка до тех пор, пока ответ не будет подтвержден как все еще свежий или не будет заменен серверной частью. В течение срока действия блокировки второй и последующие входящие запросы приведут к возврату устаревших данных, и громоподобное стадо будет держаться в страхе.
Блокировки и управление кешем: без кеша
Блокировки используются только в качестве подсказки , чтобы сделать кеш более щадящим на внутренних серверах, однако при необходимости блокировку можно обойти. Если клиент отправляет запрос с заголовком Cache-Control, вызывающим перезагрузку, любая блокировка, которая может присутствовать, будет проигнорирована, а запрос клиента будет немедленно выполнен, а кэшированная запись обновлена.
В качестве дополнительного механизма безопасности замки имеют настраиваемый максимальный срок службы. По достижении этого возраста блокировка снимается, и новому запросу предоставляется возможность создать новую блокировку. Этот максимальный возраст можно установить с помощью CacheLockMaxAge директивы, и по умолчанию он равен 5 секундам.
Пример конфигурации
Включение блокировки кеша
#
# Включить блокировку кеша
#
<IfModule mod_cache.c>
CacheLock включен
CacheLockPath "/tmp/mod_cache-lock"
CacheLockMaxAge 5
</ЕслиМодуль>
Точное управление с фильтром CACHE
В режиме работы кэша по умолчанию кэш работает как быстрый обработчик, сокращая большую часть обработки сервера и обеспечивая максимально возможную производительность кэша.
В этом режиме кэш крепится к передней части сервера, как если бы перед сервером был размещен отдельно стоящий прокси-сервер кэширования RFC 2616.
Хотя этот режим обеспечивает наилучшую производительность, администратор может обнаружить, что при определенных обстоятельствах он может захотеть выполнить дальнейшую обработку запроса после кэширования запроса, например, внедрить персонализацию в кэшированную страницу или применить ограничения авторизации к содержимому. . В этих условиях администратору часто приходится размещать независимые обратные прокси-серверы либо за, либо перед кэширующим сервером, чтобы добиться этого.
Чтобы решить эту проблему, для CacheQuickHandler
директивы можно установить значение off , и сервер будет обрабатывать все этапы, обычно обрабатываемые некэшированным запросом, включая
этапы аутентификации и авторизации .
Кроме того, администратор может дополнительно указать точную точку в цепочке фильтров , где должно выполняться кэширование, добавив
фильтр CACHE в цепочку выходных фильтров.
Например, чтобы кэшировать содержимое перед применением сжатия к ответу, поместите фильтр CACHE перед фильтром DEFLATE
, как в примере ниже:
# Кэшировать содержимое перед необязательным сжатием
CacheQuickHandler выключен
AddOutputFilterByType CACHE; DEFLATE text/plain
Другим вариантом является кэширование контента до применения персонализации mod_include (или другого фильтра обработки контента). В этом примере шаблоны, содержащие понятные теги,
mod_include кэшируются перед анализом:
# Кэшируем содержимое перед mod_include и mod_deflate
CacheQuickHandler выключен
КЭШ AddOutputFilterByType;ВКЛЮЧАЕТ;DEFLATE text/html
Вы можете разместить фильтр CACHE в любом месте в цепочке фильтров. В этом примере содержимое кэшируется после анализа с помощью
mod_include , но перед обработкой с помощью
mod_deflate :
# Кэшировать содержимое между mod_include и mod_deflate
CacheQuickHandler выключен
AddOutputFilterByType INCLUDES;CACHE;DEFLATE text/html
Предупреждение:
Если расположение
фильтра
CACHE в цепочке фильтров по какой-либо причине изменилось, вам может потребоваться
очистить кэш , чтобы убедиться, что ваши данные остаются согласованными.
mod_cache не в состоянии обеспечить это для вас.
Статус кэша и ведение журнала
После mod_cache принятия решения о том, следует ли обслуживать сущность из кеша, подробная причина такого решения записывается в среду подпроцесса в запросе под ключом состояния
кеша . Эта причина может быть зарегистрирована директивой
LogFormat следующим образом:
LogFormat "%{cache-status}e ..."
На основе принятого решения о кэшировании причина также записывается в среду подпроцесса под одним из следующих четырех ключей, в зависимости от ситуации:
- кэш-хит
- Ответ был получен из кеша.
- кэш-перепроверка
- Ответ устарел и был успешно перепроверен, а затем отправлен из кеша.
- кеш-промах
- Ответ был отправлен с вышестоящего сервера.
- кеш-инвалидация
- Кэшированный объект был признан недействительным методом запроса, отличным от GET или HEAD.
Это позволяет поддерживать условную регистрацию кэшированных запросов, как показано в следующем примере:
CustomLog "cached-requests.log" общий env=cache-hit
CustomLog "uncached-requests.log" общий env=cache-miss
CustomLog "revalidated-requests.log" общий env=cache-revalidate
CustomLog "invalidated-requests.log" общий env=cache-invalidate
Для авторов модулей доступен хук cache_status , позволяющий модулям индивидуально реагировать на результаты кэширования, указанные выше.
Директива CacheDefaultExpire
| Описание: | Длительность по умолчанию для кэширования документа, если срок действия не указан. |
|---|
| Синтаксис: | CacheDefaultExpire seconds |
|---|
| По умолчанию: | CacheDefaultExpire 3600 (one hour) |
|---|
| Контекст: | конфигурация сервера, виртуальный хост, каталог, .htaccess |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
Директива CacheDefaultExpire указывает время по умолчанию в секундах для кэширования документа, если в документе не указаны ни дата истечения срока действия, ни дата последнего изменения. Значение, указанное в директиве, CacheMaxExpire
не переопределяет этот параметр.
CacheDefaultExpire 86400
Директива CacheDetailHeader
| Описание: | Добавьте в ответ заголовок X-Cache-Detail. |
|---|
| Синтаксис: | CacheDetailHeader on|off |
|---|
| По умолчанию: | CacheDetailHeader off |
|---|
| Контекст: | конфигурация сервера, виртуальный хост, каталог, .htaccess |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
| Совместимость: | Доступно в Apache 2.3.9 и более поздних версиях. |
|---|
При CacheDetailHeader включении директивы к ответу будет добавлен заголовок X-Cache-Detail , содержащий подробную причину конкретного решения о кэшировании.
Во время разработки кэшированных служб RESTful может быть полезно иметь дополнительную информацию о решении кэширования, записанную в заголовки ответов, чтобы подтвердить, Cache-Control правильно ли использовались другие заголовки службой и клиентом.
Если используется обычный обработчик, эта директива может появиться внутри
директивы <Directory> или
<Location> . Если используется быстрый обработчик, эта директива должна появиться в контексте сервера или виртуального хоста, иначе параметр будет проигнорирован.
# Включить заголовок X-Cache-Detail
CacheDetailHeader включен
X-Cache-Detail: "conditional cache hit: entity refreshed" from localhost
Директива CacheDisable
| Описание: | Отключить кеширование указанных URL-адресов |
|---|
| Синтаксис: | CacheDisable url-string | on |
|---|
| Контекст: | конфигурация сервера, виртуальный хост, каталог, .htaccess |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
Директива CacheDisable предписывает
mod_cache не кэшировать URL-адреса на уровне
url-string или ниже .
Пример
CacheDisable "/local_files"
При использовании в <Location> директиве путь должен быть указан ниже местоположения, или, если используется слово «on», кэширование для всего местоположения будет отключено.
Пример
<Расположение "/foo">
КэшОтключить на
</местоположение>
Переменную среды no-cache можно настроить для отключения кэширования более мелкозернистого набора ресурсов в версиях 2.2.12 и более поздних.
Смотрите также
- Переменные среды в Apache
Директива CacheEnable
| Описание: | Включить кэширование указанных URL-адресов с помощью указанного диспетчера хранилища |
|---|
| Синтаксис: | CacheEnable cache_type [url-string] |
|---|
| Контекст: | конфигурация сервера, виртуальный хост, каталог |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
| Совместимость: | Строка URL из '/', применяемая для пересылки содержимого прокси в 2.2 и более ранних версиях. |
|---|
Директива CacheEnable предписывает
mod_cache кэшировать URL-адреса на уровне
url-string или ниже . Менеджер хранения кеша задается аргументом
cache_type . В качестве альтернативы директива CacheEnable
может быть помещена в
разделы <Location> или
<LocationMatch> , чтобы указать, что содержимое можно кэшировать.
cache_type disk указывает
mod_cache использовать диспетчер хранения на основе диска, реализованный mod_cache_disk . cache_type
socache предписывает mod_cache использовать диспетчер хранения на основе кэша общих объектов, реализованный
mod_cache_socache .
В случае, если пространство URL-адресов перекрывается между различными
CacheEnable директивами (как в примере ниже), каждый возможный менеджер хранилища будет работать до первого, который фактически обрабатывает запрос. Порядок, в котором запускаются диспетчеры хранения, определяется порядком директив CacheEnable
в файле конфигурации. CacheEnable
директивы внутри <Location> или
<LocationMatch> разделы обрабатываются перед глобально определенными CacheEnable директивами.
При работе в качестве прямого прокси-сервера строка URL-адреса должна как минимум начинаться с протокола, для которого должно быть включено кэширование.
# Содержимое кеша (только обычный обработчик)
CacheQuickHandler выключен
<Расположение "/foo">
CacheEnable диск
</местоположение>
# Кэшировать регулярное выражение (только обычный обработчик)
CacheQuickHandler выключен
<LocationMatch "foo$">
CacheEnable диск
</LocationMatch>
# Кэшировать все URL-адреса прокси-сервера, кроме прямого (обычный или быстрый обработчик)
КэшВключить диск /
# Кэшировать URL-адреса FTP-прокси (обычный или быстрый обработчик)
CacheEnable disk ftp://
# Кэшировать прокси-контент с сайта www.example.org (обычный или быстрый обработчик)
CacheEnable диск http://www.example.org/
Имя хоста, начинающееся с «*», соответствует всем именам хостов с этим суффиксом. Имя хоста, начинающееся с "." соответствует всем именам хостов, содержащим следующие компоненты домена.
# Соответствует www.example.org и fooexample.org
CacheEnable диск "http://*example.org/"
# Совпадает с www.example.org, но не с fooexample.org
CacheEnable диск "http://.example.org/"
Переменную среды no-cache можно настроить для отключения кэширования более мелкозернистого набора ресурсов в версиях 2.2.12 и более поздних.
Смотрите также
- Переменные среды в Apache
Директива CacheHeader
| Описание: | Добавьте в ответ заголовок X-Cache. |
|---|
| Синтаксис: | CacheHeader on|off |
|---|
| По умолчанию: | CacheHeader off |
|---|
| Контекст: | конфигурация сервера, виртуальный хост, каталог, .htaccess |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
| Совместимость: | Доступно в Apache 2.3.9 и более поздних версиях. |
|---|
Когда CacheHeader директива включена, к ответу будет добавлен заголовок X-Cache со статусом кеша этого ответа. Если используется обычный обработчик, эта директива может появиться внутри директивы <Directory>
или <Location> . Если используется быстрый обработчик, эта директива должна появиться в контексте сервера или виртуального хоста, иначе параметр будет проигнорирован.
- УДАРЯТЬ
- Сущность была свежей и обслуживалась из кеша.
- ПОДТВЕРДИТЬ
- Сущность устарела, успешно прошла повторную проверку и обслуживалась из кеша.
- СКУЧАТЬ
- Сущность была получена с вышестоящего сервера и не обслуживалась из кеша.
# Включить заголовок X-Cache
CacheHeader включен
X-Cache: HIT с локального хоста
Директива CacheIgnoreCacheControl
| Описание: | Игнорировать запрос на отказ от предоставления кэшированного контента клиенту |
|---|
| Синтаксис: | CacheIgnoreCacheControl On|Off |
|---|
| По умолчанию: | CacheIgnoreCacheControl Off |
|---|
| Контекст: | конфигурация сервера, виртуальный хост |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
Обычно запросы, содержащие значение заголовка Cache-Control: no-cache или Pragma: no-cache, не будут обслуживаться из кэша. Директива
CacheIgnoreCacheControl позволяет переопределить это поведение. CacheIgnoreCacheControl On
указывает серверу попытаться обслужить ресурс из кеша, даже если запрос содержит значения заголовка без кеша. Ресурсы, требующие авторизации, никогда не будут кэшироваться.
CacheIgnoreCacheControl On
Предупреждение:
Эта директива разрешает обслуживание из кеша, даже если клиент запросил, чтобы документ не обслуживался из кеша. Это может привести к показу устаревшего контента.
Смотрите также
-
CacheStorePrivate
-
CacheStoreNoStore
Директива CacheIgnoreHeaders
| Описание: | Не сохраняйте данные заголовки HTTP в кеше.
|
|---|
| Синтаксис: | CacheIgnoreHeaders header-string [header-string] ... |
|---|
| По умолчанию: | CacheIgnoreHeaders None |
|---|
| Контекст: | конфигурация сервера, виртуальный хост |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
В соответствии с RFC 2616 заголовки HTTP для каждого перехода не сохраняются в кэше. Следующие заголовки HTTP являются заголовками переходов и, таким образом, не сохраняются в кеше в любом случае, независимо от настройки CacheIgnoreHeaders :
-
Connection
-
Keep-Alive
-
Proxy-Authenticate
-
Proxy-Authorization
-
TE
-
Trailers
-
Transfer-Encoding
-
Upgrade
CacheIgnoreHeaders указывает дополнительные заголовки HTTP, которые не должны храниться в кеше. Например, в некоторых случаях имеет смысл запретить сохранение файлов cookie в кеше.
CacheIgnoreHeaders принимает разделенный пробелами список заголовков HTTP, которые не должны храниться в кеше. Если только заголовки переходов не должны храниться в кеше (поведение, совместимое с RFC 2616), CacheIgnoreHeaders можно установить значение
None .
Пример 1
CacheIgnoreHeaders Set-Cookie
Пример 2
CacheIgnoreHeaders
Предупреждение:
Если заголовки, подобные тем
Expires , которые необходимы для правильного управления кешем, не сохраняются из-за
CacheIgnoreHeaders настройки, поведение mod_cache не определено.
Директива CacheIgnoreNoLastMod
| Описание: | Не обращайте внимания на то, что ответ не имеет заголовка Last Modified. |
|---|
| Синтаксис: | CacheIgnoreNoLastMod On|Off |
|---|
| По умолчанию: | CacheIgnoreNoLastMod Off |
|---|
| Контекст: | конфигурация сервера, виртуальный хост, каталог, .htaccess |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
Обычно документы без даты последнего изменения не кэшируются. В некоторых случаях дата последнего изменения удаляется (
mod_include например, во время обработки) или вообще не указывается. Директива CacheIgnoreNoLastMod предоставляет способ указать, что документы без даты последнего изменения должны рассматриваться для кэширования, даже без даты последнего изменения. Если в документе не указаны ни дата последнего изменения, ни дата истечения срока действия, то значение, указанное в директиве,
CacheDefaultExpire будет использоваться для создания даты истечения срока действия.
CacheIgnoreNoLastMod On
Директива CacheIgnoreQueryString
| Описание: | Игнорировать строку запроса при кэшировании |
|---|
| Синтаксис: | CacheIgnoreQueryString On|Off |
|---|
| По умолчанию: | CacheIgnoreQueryString Off |
|---|
| Контекст: | конфигурация сервера, виртуальный хост |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
Обычно запросы с параметрами строки запроса кэшируются отдельно для каждой уникальной строки запроса. Согласно RFC 2616/13.9 это делается только в том случае, если указано время истечения срока действия. Директива
CacheIgnoreQueryString указывает кешу кэшировать запросы, даже если срок действия не указан, и отвечать кэшированным ответом, даже если строка запроса отличается. С точки зрения кэширования запрос обрабатывается так, как будто у него нет строки запроса, когда эта директива включена.
CacheIgnoreQueryString Вкл.
Директива CacheIgnoreURLSessionIdentifiers
| Описание: | Игнорировать определенные идентификаторы сеанса, закодированные в URL-адресе, при кэшировании
|
|---|
| Синтаксис: | CacheIgnoreURLSessionIdentifiers identifier [identifier] ... |
|---|
| По умолчанию: | CacheIgnoreURLSessionIdentifiers None |
|---|
| Контекст: | конфигурация сервера, виртуальный хост |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
Иногда приложения кодируют идентификатор сеанса в URL-адрес, как в следующих примерах:
-
/someapplication/image.gif;jsessionid=123456789
-
/someapplication/image.gif?PHPSESSIONID=12345678
Это приводит к тому, что кэшируемые ресурсы хранятся отдельно для каждого сеанса, что часто нежелательно. CacheIgnoreURLSessionIdentifiers позволяет определить список идентификаторов, которые удаляются из ключа, используемого для идентификации объекта в кэше, чтобы кешируемые ресурсы не сохранялись отдельно для каждого сеанса.
CacheIgnoreURLSessionIdentifiers None очищает список игнорируемых идентификаторов. В противном случае каждый идентификатор добавляется в список.
Пример 1
CacheIgnoreURLSessionIdentifiers jsessionid
Пример 2
CacheIgnoreURLSessionIdentifiers Нет
Директива CacheKeyBaseURL
| Описание: | Переопределить базовый URL-адрес ключей кэша обратного проксирования. |
|---|
| Синтаксис: | CacheKeyBaseURL URL |
|---|
| По умолчанию: | CacheKeyBaseURL http://example.com |
|---|
| Контекст: | конфигурация сервера, виртуальный хост |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
| Совместимость: | Доступно в Apache 2.3.9 и более поздних версиях. |
|---|
Когда CacheKeyBaseURL указана директива, предоставленный URL-адрес будет использоваться в качестве базового URL-адреса для вычисления URL-адреса ключей кэша в конфигурации обратного прокси-сервера. Если не указано, схема, имя хоста и порт текущего виртуального хоста используются для построения ключа кэша. Когда присутствует кластер машин и все кэшированные записи должны кэшироваться под одним и тем же ключом кэша, с помощью этой директивы можно указать новый базовый URL-адрес.
# Переопределить базовый URL-адрес ключа кэша.
CacheKeyBaseURL "http://www.example.com/"
Будьте осторожны при установке этой директивы. Если двум отдельным виртуальным хостам случайно будет присвоен один и тот же базовый URL-адрес, записи с одного виртуального хоста будут переданы другому.
Директива CacheLastModifiedFactor
| Описание: | Коэффициент, используемый для вычисления даты истечения срока действия на основе даты LastModified. |
|---|
| Синтаксис: | CacheLastModifiedFactor float |
|---|
| По умолчанию: | CacheLastModifiedFactor 0.1 |
|---|
| Контекст: | конфигурация сервера, виртуальный хост, каталог, .htaccess |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
В случае, если в документе не указана дата истечения срока действия, но указана дата последнего изменения, дата истечения срока действия может быть рассчитана на основе времени, прошедшего с момента последнего изменения документа. Директива
CacheLastModifiedFactor указывает
коэффициент , который будет использоваться при генерации этой даты истечения срока действия в соответствии со следующей формулой:
Например, если документ был последний раз изменен 10 часов назад, а
коэффициент равен 0,1, тогда срок действия будет установлен на 10 * 0,1. = 1 час. Если текущее время было 15:00, то вычисленная дата истечения срока действия будет 15:00 + 1 час = 16:00. Если срок истечения будет больше, чем установленный
, то последний имеет приоритет. expiry-period = time-since-last-modified-date * factor
expiry-date = current-date + expiry-period CacheMaxExpire
Кэшластмодифиедфактор 0,5
Директива CacheLock
| Описание: | Включите громоподобный замок стада. |
|---|
| Синтаксис: | CacheLock on|off |
|---|
| По умолчанию: | CacheLock off |
|---|
| Контекст: | конфигурация сервера, виртуальный хост |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
| Совместимость: | Доступно в Apache 2.2.15 и более поздних версиях. |
|---|
Директива CacheLock включает громкую блокировку стада для данного пространства URL.
В минимальной конфигурации следующая директива — это все, что нужно для включения блокировки громоподобного стада в системном каталоге временных файлов по умолчанию.
# Включить блокировку кеша
CacheLock включен
Директива CacheLockMaxAge
| Описание: | Установите максимально возможный возраст блокировки кэша. |
|---|
| Синтаксис: | CacheLockMaxAge integer |
|---|
| По умолчанию: | CacheLockMaxAge 5 |
|---|
| Контекст: | конфигурация сервера, виртуальный хост |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
Директива CacheLockMaxAge указывает максимальный возраст любой блокировки кэша.
Блокировка старше этого значения в секундах будет проигнорирована, и следующему входящему запросу будет предоставлена возможность восстановить блокировку. Этот механизм не позволяет медленному клиенту слишком долго обновлять объект.
Директива CacheLockPath
| Описание: | Установите каталог пути блокировки. |
|---|
| Синтаксис: | CacheLockPath directory |
|---|
| По умолчанию: | CacheLockPath /tmp/mod_cache-lock |
|---|
| Контекст: | конфигурация сервера, виртуальный хост |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
Директива CacheLockPath позволяет указать каталог, в котором создаются блокировки. По умолчанию используется временная папка системы. Блокировки состоят из пустых файлов, которые существуют только для устаревших URL-адресов в процессе выполнения, поэтому они значительно менее требовательны к ресурсам, чем традиционный дисковый кеш.
Директива CacheMaxExpire
| Описание: | Максимальное время в секундах для кэширования документа |
|---|
| Синтаксис: | CacheMaxExpire seconds |
|---|
| По умолчанию: | CacheMaxExpire 86400 (one day) |
|---|
| Контекст: | конфигурация сервера, виртуальный хост, каталог, .htaccess |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
Директива CacheMaxExpire указывает максимальное количество секунд, в течение которых кешируемые документы HTTP будут храниться без проверки исходного сервера. Таким образом, документы будут устаревшими не более чем на это количество секунд. Это максимальное значение применяется, даже если дата истечения срока действия была указана вместе с документом.
CacheMaxExpire 604800
Директива CacheMinExpire
| Описание: | Минимальное время в секундах для кэширования документа |
|---|
| Синтаксис: | CacheMinExpire seconds |
|---|
| По умолчанию: | CacheMinExpire 0 |
|---|
| Контекст: | конфигурация сервера, виртуальный хост, каталог, .htaccess |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
Директива CacheMinExpire указывает минимальное количество секунд, в течение которых кешируемые документы HTTP будут храниться без проверки исходного сервера. Это используется только в том случае, если с документом не было указано действительное время истечения срока действия.
CacheMinExpire 3600
Директива CacheQuickHandler
| Описание: | Запустите кеш из быстрого обработчика. |
|---|
| Синтаксис: | CacheQuickHandler on|off |
|---|
| По умолчанию: | CacheQuickHandler on |
|---|
| Контекст: | конфигурация сервера, виртуальный хост |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
| Совместимость: | HTTP-сервер Apache 2.3.3 и выше |
|---|
Директива CacheQuickHandler управляет фазой обработки кэша.
В включенной по умолчанию конфигурации кэш работает на этапе быстрого обработчика. На этом этапе сокращается основная часть обработки сервера, и он представляет собой наиболее производительный режим работы для типичного сервера. Кэш крепится к передней части сервера, и большая часть серверной обработки избегается.
Когда кеш отключен, он работает как обычный обработчик и подчиняется полному набору фаз при обработке запроса к серверу. Хотя этот режим медленнее, чем по умолчанию, он позволяет использовать кеш в случаях, когда требуется полная обработка, например, когда содержимое подлежит авторизации.
# Запустить кеш как обычный обработчик
CacheQuickHandler выключен
Также возможно, когда быстрый обработчик отключен, администратор может выбрать точное место в цепочке фильтров, где должно выполняться кэширование, путем добавления фильтра CACHE в цепочку.
# Кэшируем содержимое перед mod_include и mod_deflate
CacheQuickHandler выключен
КЭШ AddOutputFilterByType;ВКЛЮЧАЕТ;DEFLATE text/html
Если фильтр CACHE указан более одного раза, будет применяться последний экземпляр.
Директива CacheStaleOnError
| Описание: | Подавайте устаревший контент вместо ответов 5xx. |
|---|
| Синтаксис: | CacheStaleOnError on|off |
|---|
| По умолчанию: | CacheStaleOnError on |
|---|
| Контекст: | конфигурация сервера, виртуальный хост, каталог, .htaccess |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
| Совместимость: | Доступно в Apache 2.3.9 и более поздних версиях. |
|---|
Когда CacheStaleOnError директива включена и в кеше доступны устаревшие данные, кеш будет реагировать на ответы 5xx от серверной части, возвращая устаревшие данные вместо ответа 5xx. Хотя заголовки Cache-Control, отправляемые клиентами, будут учитываться, а необработанные ответы 5xx возвращаются клиенту по запросу, ответ 5xx, возвращаемый таким образом клиенту, не сделает содержимое в кэше недействительным.
# Подавать устаревшие данные при ошибке.
CacheStaleOnError на
Директива CacheStoreExpired
| Описание: | Попытка кэшировать ответы, которые сервер сообщает как просроченные |
|---|
| Синтаксис: | CacheStoreExpired On|Off |
|---|
| По умолчанию: | CacheStoreExpired Off |
|---|
| Контекст: | конфигурация сервера, виртуальный хост, каталог, .htaccess |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
Начиная с httpd 2.2.4, ответы, срок действия которых уже истек, не сохраняются в кеше. Директива CacheStoreExpired
позволяет переопределить это поведение.
CacheStoreExpired On указывает серверу попытаться кэшировать ресурс, если он устарел. Последующие запросы вызовут запрос If-Modified-Since исходного сервера, и ответ может быть выполнен из кеша, если внутренний ресурс не изменился.
CacheStoreExpired On
Директива CacheStoreNoStore
| Описание: | Попытаться кэшировать запросы или ответы, которые были помечены как не сохраняемые. |
|---|
| Синтаксис: | CacheStoreNoStore On|Off |
|---|
| По умолчанию: | CacheStoreNoStore Off |
|---|
| Контекст: | конфигурация сервера, виртуальный хост, каталог, .htaccess |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
Обычно запросы или ответы с Cache-Control: значения заголовка no-store не сохраняются в кеше. Директива
CacheStoreNoStore позволяет переопределить это поведение. CacheStoreNoStore On указывает серверу попытаться кэшировать ресурс, даже если он содержит значения заголовка без сохранения. Ресурсы, требующие авторизации,
никогда не будут кэшироваться.
CacheStoreNoStore On
Предупреждение:
Как описано в RFC 2616, директива no-store предназначена для «предотвращения непреднамеренного выпуска или сохранения конфиденциальной информации (например, на резервных лентах)». Включение этого параметра может привести к сохранению конфиденциальной информации в кэше. Настоящим вы предупреждены.
Смотрите также
-
CacheIgnoreCacheControl
-
CacheStorePrivate
Директива CacheStorePrivate
| Описание: | Попытка кэшировать ответы, которые сервер пометил как частные |
|---|
| Синтаксис: | CacheStorePrivate On|Off |
|---|
| По умолчанию: | CacheStorePrivate Off |
|---|
| Контекст: | конфигурация сервера, виртуальный хост, каталог, .htaccess |
|---|
| Положение дел: | Расширение |
|---|
| Модуль: | mod_cache |
|---|
Обычно ответы с Cache-Control: private значения заголовка не сохраняются в кеше. Директива CacheStorePrivate
позволяет переопределить это поведение.
CacheStorePrivate On указывает серверу попытаться кэшировать ресурс, даже если он содержит частные значения заголовка. Ресурсы, требующие авторизации,
никогда не будут кэшироваться.
CacheStorePrivate On
Предупреждение:
Эта директива разрешает кэширование, даже если вышестоящий сервер запросил, чтобы ресурс не кэшировался. Эта директива идеальна только для «частного» кеша.
Смотрите также
-
CacheIgnoreCacheControl
-
CacheStoreNoStore
