Milliseconds and dynamic time support for *_cache_valid

[avkarenow@…]

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? :)

[Maxim Dounin]

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.

[avkarenow@…]

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.

[boppy@…]

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.

[peter.volkov@…]

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.

[blloof@…]

Upvote.
Please add this feature.

[Jeff]

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

[Jeff]

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.

[SidSethi@…]

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