Re: Avoiding TCP_REFRESH_HIT

[Veiko Kukk <ve...@gmail.com>]

Just to give back to community what was the final solution

* /etc/trafficserver/header_rewrite.config [1]
cond %{READ_RESPONSE_HDR_HOOK} [AND]
cond %{STATUS} = 200
rm-header Expires
set-header Cache-Control "max-age=157784630"

* /etc/trafficserver/plugin.config [2]
header_rewrite.so header_rewrite.config

* /etc/trafficserver/records.config [3]
CONFIG proxy.config.http.cache.required_headers INT 2

[1]
https://docs.trafficserver.apache.org/en/7.1.x/admin-guide/plugins/header_rewrite.en.html
[2]
https://docs.trafficserver.apache.org/en/7.1.x/admin-guide/files/plugin.config.en.html
[3]
https://docs.trafficserver.apache.org/en/7.1.x/admin-guide/files/records.config.en.html#proxy-config-http-cache-required-headers

It's important to add max-age only to HTTP status code 200 and to set
required headers to contain max-age.
set-header overwrites existing 'Cache-Control'.


Regards,
Veiko



2017-11-24 11:24 GMT+02:00 Veiko Kukk <ve...@gmail.com>:

> Hi,
>
> 1) I don't know. ATS is not in production yet, i just noticed that it
> happened during testing. Since we are just moving from Squid to ATS, i'm
> testing latest stable ATS, thats being 7.1.1 at the moment.
>
> 2) Thank you for that! That's exatly what I was looking for, some clever
> way to overwrite ATS staleness decision.
>
> Regards,
> Veiko
>
>
> 2017-11-23 22:33 GMT+02:00 Shu Kit Chan <ch...@gmail.com>:
>
>> 1) How often does TCP_REFRESH_HIT happen? Just a wild guess. If you
>> are using ATS < 6.2.0, there is a fuzz feature that may cause this to
>> happen very once in a while.
>>
>> 2) Here is an alternative approach. you can try to use ts_lua plugin
>> with the following script.
>>
>> function cache_lookup()
>>   ts.debug('cache-lookup')
>>   -- mark stale hit as fresh hit
>>   local cache_status = ts.http.get_cache_lookup_status()
>>   if cache_status == TS_LUA_CACHE_LOOKUP_HIT_STALE then
>>     ts.debug('stale hit')
>>     ts.http.set_cache_lookup_status(TS_LUA_CACHE_LOOKUP_HIT_FRESH)
>>   end
>>   return 0
>> end
>>
>> function do_global_read_request()
>>   ts.hook(TS_LUA_HOOK_CACHE_LOOKUP_COMPLETE, cache_lookup)
>>   return 0
>> end
>>
>> 3) You can also try to debug it by turning on debug and use debug tag
>> of "http.*" and see what kind of messages are generated in traffic.out
>> when TCP_REFRESH_HIT happened. It should give you some hints on why a
>> revalidate is needed.
>>
>> Thanks. Hopefully it helps.
>>
>> Kit
>>
>>
>>
>> On Thu, Nov 23, 2017 at 10:41 AM, Stephen Washburn
>> <st...@stephenwashburn.com> wrote:
>> > Ah… sorry about that.
>> >
>> > Stephen
>> >
>> > On Nov 23, 2017, at 10:22, Veiko Kukk <ve...@gmail.com> wrote:
>> >
>> > Hi Stephen,
>> >
>> > As i wrote in my first post, i've set CONFIG
>> > proxy.config.http.cache.when_to_revalidate INT 3
>> >
>> > Veiko
>> >
>> >
>> > 2017-11-23 19:56 GMT+02:00 Stephen Washburn <
>> stephen@stephenwashburn.com>:
>> >>
>> >> Apologies if I’m missing something, but doesn’t that page say that
>> there
>> >> is an option to have it treat freshness as such:
>> >>
>> >> Traffic Server considers all HTTP objects in the cache to be
>> fresh:Never
>> >> revalidate HTTP objects in the cache with the origin server.
>> >>
>> >>
>> >> By modifying proxy.config.http.cache.when_to_revalidate
>> >>
>> >>
>> >> https://docs.trafficserver.apache.org/en/7.1.x/admin-guide/
>> files/records.config.en.html#proxy-config-http-cache-when-to-revalidate
>> >>
>> >> Stephen
>> >>
>> >> On Nov 23, 2017, at 09:26, Veiko Kukk <ve...@gmail.com> wrote:
>> >>
>> >> Now to think about it, i might have set dest_domain to wrong value.
>> >> Documentation is not that clear on that. If there are x.y.z.tld and
>> >> a.b.z.tld then what have to be written to dest_domain to capture both
>> of
>> >> those?
>> >> dest_domain=z.tld
>> >> or
>> >> dest_domain=*.*.z.tld
>> >>
>> >> Or someting else?
>> >>
>> >> Veiko
>> >>
>> >>
>> >> 2017-11-23 19:20 GMT+02:00 Veiko Kukk <ve...@gmail.com>:
>> >>>
>> >>> Hi Alan,
>> >>>
>> >>> That is what i had already done in cache.config:
>> >>> dest_domain=.*.source.tld ttl-in-cache=9999d
>> >>>
>> >>> Of cource, source.tld is actually real domain, and this did not avoid
>> >>> checking origin for object freshness, it was still considered stale
>> by ATS.
>> >>>
>> >>>
>> >>> https://docs.trafficserver.apache.org/en/7.1.x/admin-guide/
>> configuration/cache-basics.en.html#ensuring-cached-object-freshness
>> >>> describes that if Expires is present, it is used to calculate objects
>> >>> freshness. And there is no way to ignore it. I've configured now ATS
>> to
>> >>> remove Expires header and set Cache-control: max-age=157784630 with
>> header
>> >>> rewrite plugin and cond %{READ_RESPONSE_HDR_HOOK}
>> >>> Will see it that helps.
>> >>>
>> >>> Veiko
>> >>>
>> >>>
>> >>> 2017-11-23 18:38 GMT+02:00 Alan Carroll <so...@oath.com>:
>> >>>>
>> >>>> You might try fiddling with the 'cache.config' file and set a cache
>> TTL
>> >>>> of 10 years or so.
>> >>>>
>> >>>> On Thu, Nov 23, 2017 at 10:11 AM, Veiko Kukk <ve...@gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> Hi David,
>> >>>>>
>> >>>>> Objects are not fetched from ATS via browser. ATS is just internal
>> >>>>> cache. Only problem is to trick ATS into believing that object is
>> always
>> >>>>> fresh, never stale.
>> >>>>> I wonder if modifying headers before ATS (READ_RESPONSE_HDR_HOOK)
>> >>>>> removing or changing Expires and/or adding max-age to some very big
>> value
>> >>>>> might be right way to go for me.
>> >>>>>
>> >>>>> Veiko
>> >>>>>
>> >>>>>
>> >>>>> 2017-11-23 17:52 GMT+02:00 David Carlin <dc...@oath.com>:
>> >>>>>>
>> >>>>>> Have you considered adding "Cache-Control: Immutable" to these
>> objects
>> >>>>>> which will never require re-validation?  This will prevent the
>> browser from
>> >>>>>> attempting an If-Modified-Since request.
>> >>>>>>
>> >>>>>>
>> >>>>>> https://hacks.mozilla.org/2017/01/using-immutable-caching-
>> to-speed-up-the-web/
>> >>>>>>
>> >>>>>> David
>> >>>>>>
>> >>>>>> On Thu, Nov 23, 2017 at 10:07 AM, Veiko Kukk <veiko.kukk@gmail.com
>> >
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> In addition to my previous e-mail, headers that are provided by
>> >>>>>>> source to ATS:
>> >>>>>>>
>> >>>>>>> < HTTP/1.1 200 OK
>> >>>>>>> < Content-Length: 1185954
>> >>>>>>> < Accept-Ranges: bytes
>> >>>>>>> < Last-Modified: Mon, 02 Nov 2015 17:56:12 GMT
>> >>>>>>> < Etag: 92ef40097ba87bdf09efcf7e1cefd32a
>> >>>>>>> < X-Timestamp: 1446486971.39466
>> >>>>>>> < Content-Type: application/octet-stream
>> >>>>>>> < Content-Disposition: attachment;
>> >>>>>>> filename="ABIYohNyPrJNjvFsAdgN5wc8D-8Yo4ZO.m4s";
>> >>>>>>> filename*=UTF-8''ABIYohNyPrJNjvFsAdgN5wc8D-8Yo4ZO.m4s
>> >>>>>>> < Expires: Thu, 23 Nov 2017 15:27:30 GMT
>> >>>>>>> < X-Trans-Id: tx3a0af5473d5c41d38195c-005a16e30d
>> >>>>>>> < X-Openstack-Request-Id: tx3a0af5473d5c41d38195c-005a16e30d
>> >>>>>>> < Date: Thu, 23 Nov 2017 15:02:37 GMT
>> >>>>>>> < X-IPLB-Instance: 12631
>> >>>>>>>
>> >>>>>>> I assume, Expires header is here to blame and must be overriden in
>> >>>>>>> ATS config, but how? I don't have control over source, its
>> Openstack Swift
>> >>>>>>> object storage.
>> >>>>>>>
>> >>>>>>> Veiko
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 2017-11-23 16:35 GMT+02:00 Veiko Kukk <ve...@gmail.com>:
>> >>>>>>>>
>> >>>>>>>> Hi,
>> >>>>>>>>
>> >>>>>>>> Could ATS in reverse proxy mode be configured such way that it
>> would
>> >>>>>>>> never try to revalidate from source? It is known that in our
>> case, object
>> >>>>>>>> never changes (and is never refetched from source) and it is
>> desirable to
>> >>>>>>>> avoid any source validation. Validation verification adds
>> significant
>> >>>>>>>> overhead and we need to avoid it. Response to client with
>> TCP_REFRESH_HIT
>> >>>>>>>> would take 100-200ms instead of 0-10 in case of direct local
>> TCP_HIT.
>> >>>>>>>>
>> >>>>>>>> I've configured following:
>> >>>>>>>> dest_domain=.*.source.tld action=ignore-no-cache
>> >>>>>>>> dest_domain=.*.source.tld revalidate=9999d
>> >>>>>>>> dest_domain=.*.source.tld ttl-in-cache=9999d
>> >>>>>>>>
>> >>>>>>>> CONFIG proxy.config.http.cache.when_to_revalidate INT 3
>> >>>>>>>> CONFIG proxy.config.http.cache.required_headers INT 0
>> >>>>>>>>
>> >>>>>>>> But i still get TCP_REFRESH_HIT even when 9999 days have not
>> passed
>> >>>>>>>> (obviously).
>> >>>>>>>>
>> >>>>>>>> NB! ATS is used as internal cache and our 'client' never
>> explicitly
>> >>>>>>>> requests revalidation.
>> >>>>>>>>
>> >>>>>>>> Thanks,
>> >>>>>>>> Veiko
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>>
>
>