Question about proxy_cache_min_uses

J.R. themadbeaker at gmail.com
Sun May 10 14:03:20 UTC 2020


> My concern is as follows, proxy_cache_min_uses=1 effectively caches
> everything, which is too much... But proxy_cache_min_uses=2 doesn't cache
> enough. I'm struggling to understand exactly how proxy_cache_min_uses works,
> by setting it to 2 nginx needs to somehow know that 2 requests were made for
> a given piece of content. But how does it do that? And over what timeframe?
> 2 requests in the current connection buffer, 2 requests over the past 5
> mins, etc.,.

First to clarify how many hits are cached...

The first request for content no matter what can never be cached
(because obviously nginx has no idea what the resources are).

For min=1, then the second request (and then on) would hit the nginx cache...

For min=2, it would technically be the 3rd request for a resource.
This prevents your cache from filling up from single-requests for
something.

The time frame for the caching is controlled by two mechanisms...

FIRST, and probably most important is the 'proxy_cache_path'
directive, specifically the 'inactive' setting. Excluding all the
other cache settings for now, 'inactive' will expire content if it's
not re-requested within the specified time.

SECOND, is the actual cache headers for your content, of if you don't
have any relevant headers the 'proxy_cache_valid' setting. One super
IMPORTANT note, remember that nginx is caching the content AND the
header... So you DON'T want to use a cache-control 'max_age=xxx' value
(which is the number of seconds till it expires) because it will cache
the first instance and it will never get decremented until the cached
copy happens to get updated. Instead it's better to use the
'last-modified' and 'Expires' headers that specifies a fixed
date/time. Having a 'last-modified' allows for 304 responses (assuming
you have everything configured correctly). The 'expires' tag also tell
nginx's cache how long the content is valid for, superseding the
proxy_cache_valid setting.

Here's how it all breaks down... I'll use one of my sites as an example...

My content changes every 3 hours due to an update from a data feed...
So... All my caching headers will specify that future point in time
when the content will update. The cache headers tell nginx when its
cached copy is no longer valid and it needs to fetch a fresh copy. If
you don't have any caching headers then as I mentioned above nginx
will cache based on the 'proxy_cache_valid' defaults. If by some freak
accident you have your headers set to no-cache, then nothing would get
cached.

Since I know my content is valid for a max of 3 hours, I also set the
'inactive' setting to 3 hours since my 'max_size' in the
proxy_cache_path never reaches near its capacity, and I would rather
use the disk space then spend the processing power having to
re-generate the page. If storage was a concern, then one could lower
the 'inactive' setting so that only frequently requested content would
end up staying in the cache, while the rest would expire from
inactivity.

IMPORTANT NOTE: The 'inactive' setting supersedes your cache headers!
Even if your cache headers content is valid for a month, if your
'inactive' setting is set for 1 hour, and nobody requests it within an
hour, then nginx WILL expire that content.

I also have my 'proxy_cache_min_uses' set to 2, to prevent caching a
bunch of content that might only get hit once.

So, the big take away is to make sure your caching headers are good
first, then to set the nginx 'inactive' setting to a time-span that
you thing is frequent enough that people will be requesting the
content, but not so low that active content is being prematurely
expired. If its set too high, then your cache will fill up to the max
value and nginx will clean out the oldest requested content first
which is okay, but you are probably holding more content then you need
in the cache if its always 100% (or your cache size is too small).


More information about the nginx mailing list