Apache Module mod_cache
| Description: | RFC 2616 совместимый HTTP кеширующий фильтр. |
|---|---|
| Status: | Расширение |
| Module Identifier: | cache_module |
| Source File: | mod_cache.c |
Summary
CacheQuickHandler по умолчанию включено, директивы Allow и Deny будут проигнорированы. Не следует включать быстрый кеширование обработчика для любого содержимого, доступ к которому вы хотите ограничить по имени хоста клиента, адресу или переменной среды.mod_cache реализует совместимый с RFC 2616 фильтр кеширования HTTP-содержимого, с поддержкой кеширования ответов с переговорным содержимым, содержащим заголовок 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-адресе кешируемого ответа. Несколько ответов с переговорным содержимым могут храниться одновременно, однако кеширование частичного содержимого не поддерживается этим модулем.
Дополнительные подробности, обсуждения и примеры приведены в Руководстве по кешированию.
Связанные модули и директивы
| Связанные модули | Связанные директивы |
|---|---|
Пример конфигурации
Пример httpd.conf
#
# Sample Cache Configuration
#
LoadModule cache_module modules/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 disk "/"
CacheDirLevels 5
CacheDirLength 3
</IfModule>
# When acting as a proxy, don't cache the list of security updates
CacheDisable "http://security.update.server/update-list/"
</IfModule> Избегание "Thundering Herd"
Когда кэшированная запись становится устаревшей, mod_cache отправит условный запрос на бэкенд, который должен подтвердить, является ли кэшированная запись актуальной, и отправить обновленный объект, если нет.
Существует небольшой, но конечный промежуток времени между моментом, когда кэшированный объект становится устаревшим, и моментом, когда устаревший объект полностью обновляется. На загруженном сервере большое количество запросов может появиться в это время и вызвать "Thundering Herd" запросов, которые внезапно и непредсказуемо обрушатся на бэкенд.
Чтобы предотвратить "Thundering Herd", можно использовать директиву CacheLock для определения каталога, в котором создаются блокировки для URL-адресов в процессе обработки. Блокировка используется как подсказка для других запросов, чтобы либо подавить попытку кеширования (кто-то другой уже обратился за объектом), либо указать, что устаревшая запись обновляется (вместо этого будут возвращены устаревшие данные).
Первоначальное кеширование записи
Когда объект кешируется впервые, для объекта создаётся блокировка до тех пор, пока ответ не будет полностью кэширован. В течение срока действия блокировки кеш будет подавлять вторую и последующие попытки кэширования того же объекта. Хотя это не останавливает "Thundering Herd", это предотвращает попытку кеширования одного и того же объекта несколько раз одновременно.
Обновление устаревшей записи
Когда объект достигает срока своей актуальности и становится устаревшим, для объекта создаётся блокировка до тех пор, пока ответ не будет подтверждён как актуальный или заменён бэкендом. В течение срока действия блокировки последующие запросы будут получать устаревшие данные, и "Thundering Herd" будет предотвращен.
Блокировки и Cache-Control: no-cache
Блокировки используются только как подсказка, чтобы кеш был более щадящим к серверам бэкенда, однако блокировку можно переопределить при необходимости. Если клиент отправляет запрос с заголовком Cache-Control, принуждающим перезагрузку, любая существующая блокировка будет проигнорирована, запрос клиента будет выполнен немедленно, и кэшированная запись будет обновлена.
В качестве дополнительной меры предосторожности, блокировки имеют настраиваемый максимальный срок действия. После достижения этого срока действия блокировка удаляется, и новый запрос получает возможность создания новой блокировки. Этот максимальный срок действия можно установить с помощью директивы CacheLockMaxAge и по умолчанию составляет 5 секунд.
Пример конфигурации
Включение блокировки кеша
#
# Enable the cache lock
#
<IfModule mod_cache.c>
CacheLock on
CacheLockPath "/tmp/mod_cache-lock"
CacheLockMaxAge 5
</IfModule> Точный контроль с фильтром CACHE
В стандартном режиме работы кеша кеш работает как быстрый обработчик, обходя большую часть обработки сервера и обеспечивая наилучшую производительность кеша.
В этом режиме кеш присоединяется к передней части сервера, действуя так, как если бы независимый кеширующий прокси RFC 2616 был помещён перед сервером.
Хотя этот режим обеспечивает лучшую производительность, администратор может обнаружить, что в определённых случаях он может захотеть выполнить дополнительную обработку запроса после кэширования запроса, например, чтобы внедрить персонализацию в кэшированную страницу или применить ограничения авторизации к содержимому. В таких случаях администратор часто вынужден размещать независимые прокси-серверы либо позади, либо перед кеширующим сервером для достижения этой цели.
Для решения этой проблемы директиву CacheQuickHandler можно установить в выключенное состояние, и сервер будет обрабатывать все фазы, обычно обрабатываемые некэшированным запросом, включая фазы аутентификации и авторизации.
Кроме того, администратор может, при желании, указать точную точку в цепочке фильтров, где должно происходить кеширование, добавив фильтр CACHE в цепочку фильтров вывода.
Например, чтобы кэшировать содержимое перед применением сжатия к ответу, поместите фильтр CACHE перед фильтром DEFLATE, как показано в примере ниже:
# Cache content before optional compression CacheQuickHandler off AddOutputFilterByType CACHE;DEFLATE text/plain
Другой вариант — иметь кэшированное содержимое до применения персонализации фильтром mod_include (или другим фильтром обработки содержимого). В этом примере шаблоны, содержащие теги, понимаемые mod_include, кэшируются перед обработкой:
# Cache content before mod_include and mod_deflate CacheQuickHandler off AddOutputFilterByType CACHE;INCLUDES;DEFLATE text/html
Вы можете поместить фильтр CACHE в любом месте цепочки фильтров. В этом примере содержимое кэшируется после обработки фильтром mod_include, но перед обработкой фильтром mod_deflate:
# Cache content between mod_include and mod_deflate CacheQuickHandler off AddOutputFilterByType INCLUDES;CACHE;DEFLATE text/html
Предупреждение:
Если расположение фильтра CACHE в цепочке фильтров изменено по какой-либо причине, вам может потребоваться очистить кэш, чтобы обеспечить согласованность предоставляемых данных.mod_cache не может гарантировать это за вас.Статус кеша и ведение журнала
После того, как mod_cache принял решение о том, будет ли объект получен из кэша, подробное обоснование решения записывается в среду выполнения подпроцесса в запросе под ключом cache-status. Это обоснование можно записать в журнал с помощью директивы LogFormat следующим образом:
LogFormat "%{cache-status}e ..." В зависимости от принятого решения о кешировании, обоснование также записывается в среду выполнения подпроцесса под одним из следующих четырёх ключей, по мере необходимости:
- cache-hit
- Ответ был получен из кэша.
- cache-revalidate
- Ответ был устаревшим и успешно перевалидирован, затем получен из кэша.
- cache-miss
- Ответ был получен с сервера-источника.
- cache-invalidate
- Кэшированный элемент был аннулирован методом запроса, отличным от GET или HEAD.
Это позволяет поддерживать условное протоколирование кэшированных запросов, как показано в следующем примере:
CustomLog "cached-requests.log" common env=cache-hit CustomLog "uncached-requests.log" common env=cache-miss CustomLog "revalidated-requests.log" common env=cache-revalidate CustomLog "invalidated-requests.log" common 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>. Если используется быстрый обработчик, эта директива должна находиться в контексте сервера или виртуального хоста, иначе настройка будет проигнорирована.
# Enable the X-Cache-Detail header CacheDetailHeader on
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>, путь должен быть указан ниже Location, или, если используется слово "on", кэширование для всего расположения будет отключено.
Пример
<Location "/foo">
CacheDisable on
</Location> Переменная среды no-cache может быть установлена для отключения кэширования на более детальном уровне ресурсов в версиях 2.2.12 и более поздних.
См. также
Директива 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-string должен, по меньшей мере, начинаться с протокола, для которого должно быть включено кэширование.
# Cache content (normal handler only)
CacheQuickHandler off
<Location "/foo">
CacheEnable disk
</Location>
# Cache regex (normal handler only)
CacheQuickHandler off
<LocationMatch "foo$">
CacheEnable disk
</LocationMatch>
# Cache all but forward proxy url's (normal or quick handler)
CacheEnable disk /
# Cache FTP-proxied url's (normal or quick handler)
CacheEnable disk ftp://
# Cache forward proxy content from www.example.org (normal or quick handler)
CacheEnable disk http://www.example.org/ Имя хоста, начинающееся с "*", соответствует всем именам хостов с таким суффиксом. Имя хоста, начинающееся с ".", соответствует всем именам хостов, содержащим следующие компоненты домена.
# Match www.example.org, and fooexample.org CacheEnable disk "http://*example.org/" # Match www.example.org, but not fooexample.org CacheEnable disk "http://.example.org/"
Переменная среды no-cache может быть установлена для отключения кэширования на более детальном уровне ресурсов в версиях 2.2.12 и более поздних.
См. также
Директива CacheHeader
| Описание: | Добавить заголовок X-Cache в ответ. |
|---|---|
| Синтаксис: | CacheHeader on|off |
| По умолчанию: | CacheHeader off |
| Контекст: | настройка сервера, виртуальный хост, каталог, .htaccess |
| Статус: | Расширение |
| Модуль: | mod_cache |
| Совместимость: | Доступно в Apache 2.3.9 и более поздних версиях |
При включенной директиве CacheHeader, в ответ будет добавлен заголовок X-Cache со статусом кэша этого ответа. Если используется обычный обработчик, эта директива может находиться в директиве <Directory> или <Location> . Если используется быстрый обработчик, эта директива должна находиться в контексте сервера или виртуального хоста, иначе настройка будет проигнорирована.
- HIT
- Сущность была актуальной и была получена из кэша.
- REVALIDATE
- Сущность была устаревшей, успешно перевалидирована и была получена из кэша.
- MISS
- Сущность была получена с сервера-источника и не была получена из кэша.
# Enable the X-Cache header CacheHeader on
X-Cache: HIT from localhost
Директива CacheIgnoreCacheControl
| Описание: | Игнорировать запросы о невыводе кэшированного содержимого клиенту |
|---|---|
| Синтаксис: | CacheIgnoreCacheControl On|Off |
| По умолчанию: | CacheIgnoreCacheControl Off |
| Контекст: | настройка сервера, виртуальный хост |
| Статус: | Расширение |
| Модуль: | mod_cache |
В обычном режиме запросы, содержащие заголовок Cache-Control: no-cache или Pragma: no-cache, не будут выведены из кэша. Директива CacheIgnoreCacheControl позволяет переопределить это поведение. CacheIgnoreCacheControl On указывает серверу попытаться вывести ресурс из кэша, даже если запрос содержит заголовки no-cache. Ресурсы, требующие авторизации, никогда не будут кэшироваться.
CacheIgnoreCacheControl On
Предупреждение:
Эта директива позволит выводить содержимое из кэша, даже если клиент запросил не выводить документ из кэша. Это может привести к выдаче устаревшего содержимого.См. также
Директива CacheIgnoreHeaders
| Описание: | Не сохранять указанные HTTP-заголовки в кэше. |
|---|---|
| Синтаксис: | CacheIgnoreHeaders header-string [header-string] ... |
| По умолчанию: | CacheIgnoreHeaders None |
| Контекст: | настройка сервера, виртуальный хост |
| Статус: | Расширение |
| Модуль: | mod_cache |
Согласно RFC 2616, заголовки HTTP, передаваемые поэтапно, не сохраняются в кэше. Следующие заголовки HTTP являются такими заголовками и, следовательно, не сохраняются в кэше в любом случае, независимо от настроек CacheIgnoreHeaders:
ConnectionKeep-AliveProxy-AuthenticateProxy-AuthorizationTETrailersTransfer-EncodingUpgrade
CacheIgnoreHeaders указывает дополнительные HTTP-заголовки, которые не должны сохраняться в кэше. Например, в некоторых случаях имеет смысл предотвратить сохранение cookie в кэше.
CacheIgnoreHeaders принимает список HTTP-заголовков, разделенных пробелами, которые не должны сохраняться в кэше. Если необходимо сохранить только заголовки, передаваемые поэтапно (соответствующее поведению RFC 2616), CacheIgnoreHeaders может быть установлено на None.
Пример 1
CacheIgnoreHeaders Set-Cookie
Пример 2
CacheIgnoreHeaders None
Предупреждение:
Если заголовки, такие как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 On
Директива 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 None
Директива CacheKeyBaseURL
| Описание: | Переопределить базовый URL обратного прокси-ключа кеша. |
|---|---|
| Синтаксис: | CacheKeyBaseURL URL |
| Контекст: | конфигурация сервера, виртуальный хост |
| Статус: | Расширение |
| Модуль: | mod_cache |
| Совместимость: | Доступно в Apache 2.3.9 и более поздних версиях |
Когда указана директива CacheKeyBaseURL, указанный URL будет использоваться в качестве базового URL для расчета URL ключей кеша в конфигурации обратного прокси. Если не указано, то схема, имя хоста и порт текущего виртуального хоста используются для построения ключа кеша. Когда присутствует кластер машин и все кэшированные записи должны быть кэшированы под одним ключом кеша, с помощью этой директивы можно указать новый базовый URL.
# Override the base URL of the cache key. CacheKeyBaseURL "http://www.example.com/"
Директива CacheLastModifiedFactor
| Описание: | Коэффициент, используемый для вычисления даты срока действия на основе даты последнего изменения. |
|---|---|
| Синтаксис: | CacheLastModifiedFactor float |
| По умолчанию: | CacheLastModifiedFactor 0.1 |
| Контекст: | конфигурация сервера, виртуальный хост, директория, .htaccess |
| Статус: | Расширение |
| Модуль: | mod_cache |
В случае, если документ не предоставляет дату срока действия, но предоставляет дату последнего изменения, дату срока действия можно рассчитать на основе времени, прошедшего с момента последнего изменения документа. Директива CacheLastModifiedFactor указывает коэффициент, который будет использоваться для генерации этой даты срока действия по следующей формуле: expiry-period = time-since-last-modified-date * factor expiry-date = current-date + expiry-period Например, если документ был изменен 10 часов назад, а коэффициент равен 0,1, то период срока действия будет установлен на 10*0,1 = 1 час. Если текущее время было 15:00, то вычисленная дата срока действия будет 15:00 + 1 час = 16:00. Если период срока действия будет больше, чем тот, который задан CacheMaxExpire, то последний имеет приоритет.
CacheLastModifiedFactor 0.5
Директива CacheLock
| Описание: | Включить блокировку thundering herd. |
|---|---|
| Синтаксис: | CacheLock on|off |
| По умолчанию: | CacheLock off |
| Контекст: | конфигурация сервера, виртуальный хост |
| Статус: | Расширение |
| Модуль: | mod_cache |
| Совместимость: | Доступно в Apache 2.2.15 и более поздних версиях |
Директива CacheLock включает блокировку thundering herd для заданного URL-пространства.
В минимальной конфигурации следующая директива необходима для включения блокировки thundering herd в стандартный системный временный каталог.
# Enable cache lock CacheLock on
Директива 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 |
| Совместимость: | Apache HTTP Server 2.3.3 и более поздние версии |
Директива CacheQuickHandler управляет фазой обработки кеша.
В стандартной включенной конфигурации кеш работает в фазе быстрого обработчика. Эта фаза обходит большую часть обработки сервера и представляет собой наиболее производительный режим работы для типичного сервера. Кэш встраивается в начало сервера, и большая часть обработки сервера избегается.
При отключении кеш работает как обычный обработчик и подчиняется полному набору фаз при обработке запроса сервера. Хотя этот режим медленнее, чем по умолчанию, он позволяет использовать кэш в случаях, когда требуется полная обработка, например, когда контент подвержен авторизации.
# Run cache as a normal handler CacheQuickHandler off
Также при отключенном быстром обработчике администратор может выбрать точное место в цепочке фильтров, где должно выполняться кеширование, добавив фильтр CACHE в цепочку.
# Cache content before mod_include and mod_deflate CacheQuickHandler off AddOutputFilterByType CACHE;INCLUDES;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 не будет делать недействительным содержимое в кэше.
# Serve stale data on error. CacheStaleOnError on
Директива CacheStoreExpired
| Описание: | Попытка кэширования ответов, которые сервер сообщает как устаревшие |
|---|---|
| Синтаксис: | CacheStoreExpired On|Off |
| Значение по умолчанию: | CacheStoreExpired Off |
| Контекст: | настройка сервера, виртуальный хост, директория, .htaccess |
| Статус: | Расширение |
| Модуль: | mod_cache |
Начиная с httpd 2.2.4, ответы, которые уже истекли, не сохраняются в кэше. Директива CacheStoreExpired позволяет переопределить это поведение. CacheStoreExpired Включение позволяет серверу пытаться кэшировать ресурс, если он устарел. Последующие запросы будут вызывать запрос If-Modified-Since к исходному серверу, и ответ может быть выполнен из кэша, если ресурс на бэкенде не изменился.
CacheStoreExpired On
Директива CacheStoreNoStore
| Описание: | Попытка кэширования запросов или ответов, помеченных как no-store. |
|---|---|
| Синтаксис: | CacheStoreNoStore On|Off |
| Значение по умолчанию: | CacheStoreNoStore Off |
| Контекст: | настройка сервера, виртуальный хост, директория, .htaccess |
| Статус: | Расширение |
| Модуль: | mod_cache |
Обычно запросы или ответы с заголовками Cache-Control: no-store не сохраняются в кэше. Директива CacheStoreNoStore позволяет переопределить это поведение. CacheStoreNoStore Включение позволяет серверу пытаться кэшировать ресурс, даже если он содержит заголовки no-store. Ресурсы, требующие авторизации, никогда не кэшируются.
CacheStoreNoStore On
Предупреждение:
Как описано в RFC 2616, директива no-store предназначена для «предотвращения непреднамеренной публикации или хранения конфиденциальной информации (например, на резервных копиях)». Включение этой опции может хранить конфиденциальную информацию в кэше. Об этом предупреждают.См. также
Директива CacheStorePrivate
| Описание: | Попытка кэширования ответов, помеченных сервером как private |
|---|---|
| Синтаксис: | CacheStorePrivate On|Off |
| Значение по умолчанию: | CacheStorePrivate Off |
| Контекст: | настройка сервера, виртуальный хост, директория, .htaccess |
| Статус: | Расширение |
| Модуль: | mod_cache |
Обычно ответы с заголовками Cache-Control: private не сохраняются в кэше. Директива CacheStorePrivate позволяет переопределить это поведение. CacheStorePrivate Включение позволяет серверу пытаться кэшировать ресурс, даже если он содержит заголовки private. Ресурсы, требующие авторизации, никогда не кэшируются.
CacheStorePrivate On
Предупреждение:
Эта директива позволит кэшировать, даже если upstream-сервер запросил, чтобы ресурс не кэшировался. Эта директива подходит только для 'частного' кэша.См. также
© 2018 The Apache Software Foundation
Licensed under the Apache License, Version 2.0.
https://httpd.apache.org/docs/2.4/en/mod/mod_cache.html