traeak commented on code in PR #13611:
URL: https://github.com/apache/trafficserver/pull/13611#discussion_r4010177425
##########
doc/admin-guide/files/records.yaml.en.rst:
##########
@@ -2800,6 +2800,24 @@ Cache Control
You can monitor this metric and know when its safe to turn this feature off
as the cache wraps around.
+ Two costs come with enabling this. Every cache miss performs a second
+ lookup, so a tier with a low hit ratio roughly doubles its cache lookup
+ load for the duration. And an object found under the previous key is
+ revalidated *without* conditional headers, because a ``304`` cannot be
+ applied to it: the write that would carry the update is a create under the
+ new key rather than an update of the old one. The origin therefore returns
+ the full response, which is stored under the new key. The copy under the
+ previous key is left in place to age out on its own, since nothing reports
+ that the new object reached disk; it stops being read as soon as the new key
+ resolves, so both keys briefly hold the object. Each object pays this once,
+ but on a large cache the aggregate is a bandwidth event worth sizing before
+ enabling the setting in production.
Review Comment:
redone
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
