Leif Hedstrom created TS-4235:
---------------------------------
Summary: Deprecate fuzzy cache revalidation ?
Key: TS-4235
URL: https://issues.apache.org/jira/browse/TS-4235
Project: Traffic Server
Issue Type: Improvement
Components: Configuration, HTTP
Reporter: Leif Hedstrom
I'm starting this as a discussion here. I think there are good reasons to
deprecate (for now) and later remove the fuzz logic. These configs are
currently in place:
{code}
{RECT_CONFIG, "proxy.config.http.cache.fuzz.time", RECD_INT, "240",
RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
{RECT_CONFIG, "proxy.config.http.cache.fuzz.min_time", RECD_INT, "0",
RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
{RECT_CONFIG, "proxy.config.http.cache.fuzz.probability", RECD_FLOAT,
"0.005", RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
{code}
The reason for eliminating these are:
1) They are difficult to setup correctly, particularly if you have a mix of
various cache TTL on objects.
2) Currently, they have next to no value, since you lock out all other readers
from the object anyways. So you are likely to benefit / use this only for
objects which are infrequently accessed.
3) With the new proxy.config.http.cache.open_write_fail_action it's possible
that #2 improves, but in that case, I'd argue that if you allow it to serve
stale, you are better off letting it expire and not "prematurely" revalidate
the object.
4) It seems to cause confusing behavior as it is today (with default settings),
e.g. anything with less than 240s TTL is likely to trip up and prematurely
expire long before intended (this is why we added the
proxy.config.http.cache.fuzz.min_time option, but it's disabled by default, and
makes configuration even more complicated).
So what does everyone think? Is anyone actually using and relying on the fuzz
logic? It feels better to spend some time on adding more features to the
fail_action feature.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
