Opened 8 years ago

Last modified 4 months ago

#853 accepted enhancement

Поведение cache_use_stale updating если новые ответы нельзя кешировать

Reported by: Oleksandr Typlyns'kyi Owned by:
Priority: minor Milestone:
Component: nginx-core Version: 1.9.x
Keywords: Cc:
uname -a: FreeBSD 10.1-RELEASE-p6 GENERIC amd64
nginx -V: nginx version: nginx/1.9.7
built with OpenSSL 1.0.1l-freebsd 15 Jan 2015
TLS SNI support enabled
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx-error.log --user=www --group=www --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx-access.log --with-http_flv_module --with-http_geoip_module --with-http_image_filter_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_stub_status_module --with-http_sub_module --with-pcre --with-http_ssl_module

Description

Конфигурация следующая:
fastcgi_cache_path /var/tmp/nginx/fastcgi_cache levels=1:2 keys_zone=fcgi_cache:16m max_size=1024m inactive=35m;
fastcgi_cache_revalidate on;

fastcgi_cache fcgi_cache;
fastcgi_cache_valid 200 301 302 304 10m;
fastcgi_cache_valid 404 2m;
fastcgi_cache_use_stale updating error timeout invalid_header http_500 http_503;
fastcgi_cache_key "$request_method|$host|$uri|$args";
fastcgi_no_cache $cookie_nocache $arg_nocache $cookie_NRGNSID $cookie_NRGNTourSID $cookie_failed_login;
fastcgi_cache_bypass $cookie_nocache $arg_nocache $cookie_NRGNSID $cookie_NRGNTourSID $cookie_failed_login;

Сейчас бекенд отвечает 200 с заголовками "Cache-Control: no-store, no-cache, must-revalidate" и "Pragma: no-cache".
Но две недели назад некоторое время там было 302 без запрета кеширования и ответ попал в кеш по fastcgi_cache_valid 10m.
После этого одинокие запросы получают upstream_cache_status EXPIRED и ответ бекенда, но если несколько приходят одновременно, то срабатывает UPDATING и редирект из кеша двухнедельной давности.
Запросы приходят регулярно и удаление по inactive=35m не происходит.

Поведение полностью объяснимо механикой работы кеша, но не с точки зрения человеческих ожиданий.
Хотелось бы иметь механизм инвалидации таких устаревших данных из кеша кроме удаления элементов на файловой системе внешним скриптом.
Например, ещё один параметр для cache_path, который будет задавать максимальное время жизни в кеше expired элементов, даже если к ним есть обращения.

Change History (8)

comment:1 by Maxim Dounin, 8 years ago

Status: newaccepted

See also this thread in the nginx-devel mailing list:
http://mailman.nginx.org/pipermail/nginx-devel/2015-November/007531.html.

comment:2 by Oleksandr Typlyns'kyi, 8 years ago

Да, я помнил о том обсуждении, но не потрудился отыскать и дать ссылку - только просмотрел наличие похожих тикетов.
И даже без него понимаю востребованность одновременной работы кеша с его обходом по cache_bypass, учета параметров no_cache и заголовков ответа бекенда, cache_use_stale при ошибках и т.п.
Потому и предлагаю не особый способ обработки ответов при updating, а дополнительную ручку по типу inactive.
Если предложение имеет право на жизнь и вероятность наломать дров в этом месте небольшая, то могу попробовать сделать patch.

comment:3 by Maxim Dounin, 8 years ago

IMHO, параметр proxy_cache_path - это не совсем правильный путь. Мне сейчас представляются наиболее разумными какие-то такие варианты:

  • Директива или параметр, ограничивающая возможность использования устаревших ответов по proxy_cache_use_stale, a la RFC 5861.
  • Директива, позволяющая бекенду сказать "ответ из кеша следует удалить", что-то аналогичное proxy_no_cache, но подразумевающую удаление/инвалидацию ранее закешированного ответа.

comment:4 by Maxim Dounin, 4 years ago

See also #1862.

comment:5 by Maxim Dounin, 2 years ago

See also #2274.

comment:6 by Maxim Dounin, 4 months ago

See also #2563.

comment:7 by Maxim Dounin, 4 months ago

See also #1614.

comment:8 by Maxim Dounin, 4 months ago

See also #2569.

Note: See TracTickets for help on using tickets.