Парк обратных прокси-серверов Apache 2.4 на экземпляре AWS EC2, направленных для кеширования в кластер кэша памяти ElastiCache. Довольно типичный материал.
Директива CacheDetailHeader включена и регулярно отправляет значение «промах в кеше: кеш не желает сохранять ответ» из hostname.my.domain, который необычно устойчив к поиску в Google.
Я проверил связь между экземплярами и кластером кеша и могу наблюдать за периодическими «статистическими» взаимодействиями между экземпляром и кластером, которые кажутся успешными. Я могу взаимодействовать с сервером через telnet, так что эта часть надежна.
Дело в том, что сервер Apache редко даже пытается «установить» значение, что заставляет меня думать, что «готовность» Apache хранить ответ является проблемой.
Типичное подмножество заголовка ответа от восходящего потока похоже на это для HTTPS-запроса random-image.png
Cache-Control: public
Cache-Control: max-age=31535000
ETag: "*(a value)*"
Expires: Tue, 27 Nov 2018 18:38:04 GMT *(24 hours from now)*
Нет Set-Cookie, нет заголовков запросов, которые могут помешать кешированию.
В конечном итоге вопрос заключается в следующем: что еще могло убедить Apache «не желать» кэширования?
Заголовки будут отправляться либо из apache, если вы настроили определенные значения для типов файлов, либо из вашего бэкэнда либо в коде, либо с внутреннего HTTP-сервера. Эти заголовки элементов управления кешем выглядят как значения по умолчанию, что предполагает, что ничего явно не установлено. Что доставляет контент? Я должен признать, что мне пришлось искать mod_cache_socache, но он вообще не мог устанавливать заголовки.
Если посмотреть на «готовность», документация предполагает, что это может быть связано с тем, что ваш бэкэнд не предоставляет даты модификации, хеши или другие индикаторы свежести. Также не запутайтесь с заголовками внешнего интерфейса и содержимым кеша. Не зная больше, я предполагаю, что вам потребуется некоторая детализация в правилах кеширования и правилах заголовков внешнего интерфейса.