Opened 6 years ago

Last modified 20 months ago

#1505 new enhancement

Milliseconds and dynamic time support for *_cache_valid

Reported by: avkarenow@… Owned by:
Priority: minor Milestone:
Component: other Version: 1.12.x
Keywords: Cc:
uname -a: FreeBSD 11.1-RELEASE-p4
nginx -V: nginx version: nginx/1.12.2
built with OpenSSL 1.0.2k-freebsd 26 Jan 2017
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 --modules-path=/usr/local/libexec/nginx --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_addition_module --with-http_auth_request_module --add-dynamic-module=/wrkdirs/usr/ports/www/nginx/work/headers-more-nginx-module-84241e4 --with-http_dav_module --with-http_flv_module --with-http_gzip_static_module --with-http_gunzip_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_stub_status_module --with-http_sub_module --add-module=/wrkdirs/usr/ports/www/nginx/work/ngx_devel_kit-0.3.0 --add-dynamic-module=/wrkdirs/usr/ports/www/nginx/work/lua-nginx-module-0.10.8 --with-pcre --add-dynamic-module=/wrkdirs/usr/ports/www/nginx/work/passenger-5.1.11/src/nginx_module --with-http_v2_module --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads --with-mail=dynamic --with-mail_ssl_module --with-http_ssl_module

Description

Hello,

At this moment cache doesn't work with milliseconds like:
proxy_cache_valid 200 200ms;
nginx: [emerg] invalid time value "200ms"

Useful will be also to set time via variable:
set $valid_time "200ms";
proxy_cache_valid 200 $valid_time;

Any chance for it? :)

Change History (8)

in reply to:  description comment:1 by Maxim Dounin, 6 years ago

Type: defectenhancement

Replying to avkarenow@…:

At this moment cache doesn't work with milliseconds like:
proxy_cache_valid 200 200ms;
nginx: [emerg] invalid time value "200ms"

As of now, cache validity time can only be set with seconds granularity, much like in the Cache-Control: max-age= and Expires headers.

While currently there are no plans to change this, I think we can consider adding milliseconds if there are enough requests for this. Likely there will be various implementation problems though, as 32-bit signed integer can't hold more than 24 days in milliseconds.

Useful will be also to set time via variable:

set $valid_time "200ms";
proxy_cache_valid 200 $valid_time;

Unless there are details on how do you plan to use it, I don't think it worth the effort. If you need to specify different validity times for different responses, you can use appropriate headers returned by the backend server, or use different location{} blocks with different proxy_cache_valid set.

comment:2 by avkarenow@…, 6 years ago

We have one big virtual host (about ~3-5k domains on each server).
Now we use new location for every "valid time" but we want to more automatic that process. The best way is to have a dynamic configuration in one location.

comment:3 by boppy@…, 3 years ago

I would also opt in for a more dynamic way to configure proxy_cache_valid. I currently have the proxy settings for each location, but would like to have them more centralized. I have multiple maps and (in some cases) a lua-based logic to alter the proxy_cache_key.

Currently, I can neither use an if nor a variable for proxy_cache_valid what would reduce the config by many lines, if available.

I also tried to have a "final" location with proxy_cache_valid being set in the other locations, what does not seem to work either.

Would be great to introduce variables to proxy_cache_key.

comment:4 by peter.volkov@…, 3 years ago

We use caching to limit the number of requests on upstream servers. We want to send 10 requests per second that is why we want a 100ms cache.

comment:5 by blloof@…, 2 years ago

Upvote.
Please add this feature.

comment:6 by Jeff, 20 months ago

Upvote. Would like to set this value to 200ms to allow up to 5 requests a second to fetch data.

comment:7 by Jeff, 20 months ago

A colleague of mine made an interesting suggestion which allowed for a nice workaround in my scenario.

I have complete control over the client here, so I was able to add a cache buster to the request. The technique is to use an epoch timestamp to the request and have nginx server use this in the cache-key. Round the timestamp to the nearest 200ms, thus enabling 5 requests per second.

comment:8 by SidSethi@…, 20 months ago

I'd +1 adding the ability to have millisecond level granularity for proxy_cache_valid, either as 200ms or 0.2s.

This seems like a very valuable and common usecase, curious about the thinking behind not adding it earlier? Maybe there's a gap in my thinking here

Note: See TracTickets for help on using tickets.