Hi all,
We’ve been discussing eliminating the fuzzy pre-revalidation option from ATS,
so I’d like to hear any feedback on anyone that’s actually using and relying on
this feature before going ahead. Likely what we’d do then is to turn it off
completely for 7.0.0, and code removal for 8.0.0 if everyone agrees. First, let
me explain how this is supposed to work:
1) You specify how long before an object goes stale that it can consider doing
the pre-revalidation. This is default to 240s (4 minutes).
proxy.config.http.cache.fuzz.time
2) You specify the random (fuzz) chance that a client request can trigger the
revalidation. This is a floating number, default is 0.005 (0.5% chance). This
can only trigger if 1) is satisfied.
proxy.config.http.cache.fuzz.probability
The arguments against the fuzzy logic is (at least):
1) It is really, really difficult to configure, since it’s a random chance.
This means that you have to roughly know how often an object is fetched in a 4
minute (or whatever you configure) interval, such that at least one client
triggers the fuzz percentage limit. For example, in the default setting, you
need on average 100 requests on an object in a 4 minute interval to trigger.
This means that if you are getting 1000 req/sec for an object, it will almost
immediately trigger a revalidation for that object. As you can imagine, this is
a difficult thing to configure, because not all URLs are the same etc. So what
works well for URL A might work poorly for URL B.
2) The timer on proxy.config.http.cache.fuzz.time is also not a one size fit
all. For example, if you have objects with a CC: max-age which is less than
240s, and you get reasonable traffic on those objects, they will always
revalidate. Not exactly what you intended. This is why we also added an
optional “min” setting (proxy.config.http.cache.fuzz.min_time), which of course
makes it even harder to configured …
3) All that said, the end result is that we generally don’t really benefit from
this at all, because the objects gets write locked early anyways, and likely
acts really the same as it would if you just let it expire normally.
Now, 3) can / should be accomplished and alleviated with the new setting
proxy.config.http.cache.open_write_fail_action=2, but i’m personally having
some issues getting that to behave as I’d expect. However, if
proxy.config.http.cache.open_write_fail_action did in fact work as it should,
the need for fuzzy revalidation is again mostly pointless. (I can think of one
use case where you have short TTL objects, and you really don’t want to server
stale ever, then the fuzzy might be better, but then again, you might as well
just lower your TTL on the object accordingly :).
Thoughts?
— Leif
