Мы запускаем NGINX перед нашим внутренним сервером.
Мы пытаемся включить ] proxy_cache_background_update функция, позволяющая NGINX асинхронно обновлять кеш и обслуживать СТЕПЕННЫЙ контент при этом.
Однако мы замечаем, что он по-прежнему медленно доставляет СТЕПЕННЫЙ контент, как будто он не обслуживается из кеша. Время, необходимое для истечения срока действия элемента, очень велико и явно не обслуживается из кеша - вы можете сказать, что он идет на внутренний сервер, получает обновление и доставляет его клиенту.
Вот наша конфигурация от NGINX:
proxy_cache_revalidate on;
proxy_ignore_headers Expires;
proxy_cache_background_update on;
Наш внутренний сервер доставляет следующие заголовки:
HTTP/1.1 200 OK
Date: Thu, 28 Feb 2019 21:07:09 GMT
Server: Apache
Cache-Control: max-age=1800, stale-while-revalidate=604800
Content-Type: text/html; charset=UTF-8
При попытке получить страницу с истекшим сроком действия мы действительно замечаем следующий заголовок:
X-Cache: STALE
Однако при отправке этого ответа он очень медленный, как если бы он связался с внутренним сервером и сделал это в realtime.
Версия NGINX:
$ nginx -v
nginx version: nginx/1.15.9
Приветствуются любые предложения, советы и изменения конфигурации.
ОБНОВЛЕНИЕ
Похоже, что сервер nginx соблюдает , обслуживающий устаревший контент (как у нас проверено), но он также обновляет кеш из бэкэнда по тому же запросу / потоку, что приводит к медленному времени ответа клиенту. Т.е. похоже, он полностью игнорирует директиву proxy_cache_background_update on;
и не обновляет в фоновом режиме по отдельному подзапросу (асинхронно).
Я думаю, вам не хватает обновления proxy_cache_use_stale;
Из документации для этого параметра:
параметр
обновление
позволяет использовать устаревший кэшированный ответ, если он в настоящее время обновляется.
А для proxy_cache_background_update
они говорят следующее:
Обратите внимание, что необходимо разрешить использование устаревшего кэшированного ответа при его обновлении.
Что и есть proxy_cache_use_stale обновление;
выполняет.
Пожалуйста, перейдите в тикет:
https://trac.nginx.org/nginx/ticket/1738#comment:6
Похоже, это повторно обнаруженная ошибка.