Opened 9 years ago
Last modified 12 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 , 9 years ago
| Status: | new → accepted |
|---|
comment:2 by , 9 years ago
Да, я помнил о том обсуждении, но не потрудился отыскать и дать ссылку - только просмотрел наличие похожих тикетов.
И даже без него понимаю востребованность одновременной работы кеша с его обходом по cache_bypass, учета параметров no_cache и заголовков ответа бекенда, cache_use_stale при ошибках и т.п.
Потому и предлагаю не особый способ обработки ответов при updating, а дополнительную ручку по типу inactive.
Если предложение имеет право на жизнь и вероятность наломать дров в этом месте небольшая, то могу попробовать сделать patch.
comment:3 by , 9 years ago
IMHO, параметр proxy_cache_path - это не совсем правильный путь. Мне сейчас представляются наиболее разумными какие-то такие варианты:
- Директива или параметр, ограничивающая возможность использования устаревших ответов по
proxy_cache_use_stale, a la RFC 5861. - Директива, позволяющая бекенду сказать "ответ из кеша следует удалить", что-то аналогичное
proxy_no_cache, но подразумевающую удаление/инвалидацию ранее закешированного ответа.
See also this thread in the nginx-devel mailing list:
http://mailman.nginx.org/pipermail/nginx-devel/2015-November/007531.html.