[jira] [Updated] (TS-4235) Deprecate fuzzy cache revalidation ?

["Leif Hedstrom (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TS-4235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Leif Hedstrom updated TS-4235:
------------------------------
    Fix Version/s:     (was: 6.2.0)
                   7.0.0

> 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
>            Assignee: Leif Hedstrom
>             Fix For: 7.0.0
>
>
> 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)