Avoiding TCP_REFRESH_HIT

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Avoiding TCP_REFRESH_HIT

Veiko Kukk
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

Reply | Threaded
Open this post in threaded view
|

Re: Avoiding TCP_REFRESH_HIT

Veiko Kukk
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 <[hidden email]>:
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


Reply | Threaded
Open this post in threaded view
|

Re: Avoiding TCP_REFRESH_HIT

David Carlin-2
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.


David

On Thu, Nov 23, 2017 at 10:07 AM, Veiko Kukk <[hidden email]> 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 <[hidden email]>:
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



Reply | Threaded
Open this post in threaded view
|

Re: Avoiding TCP_REFRESH_HIT

Veiko Kukk
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 <[hidden email]>:
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.


David

On Thu, Nov 23, 2017 at 10:07 AM, Veiko Kukk <[hidden email]> 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 <[hidden email]>:
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




Reply | Threaded
Open this post in threaded view
|

Re: Avoiding TCP_REFRESH_HIT

Alan Carroll-2
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 <[hidden email]> 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 <[hidden email]>:
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.


David

On Thu, Nov 23, 2017 at 10:07 AM, Veiko Kukk <[hidden email]> 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 <[hidden email]>:
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





Reply | Threaded
Open this post in threaded view
|

Re: Avoiding TCP_REFRESH_HIT

Veiko Kukk
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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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.


David

On Thu, Nov 23, 2017 at 10:07 AM, Veiko Kukk <[hidden email]> 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 <[hidden email]>:
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






Reply | Threaded
Open this post in threaded view
|

Re: Avoiding TCP_REFRESH_HIT

Veiko Kukk
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 <[hidden email]>:
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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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.


David

On Thu, Nov 23, 2017 at 10:07 AM, Veiko Kukk <[hidden email]> 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 <[hidden email]>:
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







Reply | Threaded
Open this post in threaded view
|

Re: Avoiding TCP_REFRESH_HIT

David Carlin-2
I have not played with cache.config much, but one setting that may impact dest_domain value is whether or not proxy.config.url_remap.pristine_host_hdr is enabled.

David

On Thu, Nov 23, 2017 at 12:26 PM, Veiko Kukk <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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.


David

On Thu, Nov 23, 2017 at 10:07 AM, Veiko Kukk <[hidden email]> 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 <[hidden email]>:
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








Reply | Threaded
Open this post in threaded view
|

Re: Avoiding TCP_REFRESH_HIT

Stephen Washburn
In reply to this post by Veiko Kukk
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


Stephen

On Nov 23, 2017, at 09:26, Veiko Kukk <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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.


David

On Thu, Nov 23, 2017 at 10:07 AM, Veiko Kukk <[hidden email]> 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 <[hidden email]>:
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







Reply | Threaded
Open this post in threaded view
|

Re: Avoiding TCP_REFRESH_HIT

Veiko Kukk
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 <[hidden email]>:
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


Stephen

On Nov 23, 2017, at 09:26, Veiko Kukk <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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.


David

On Thu, Nov 23, 2017 at 10:07 AM, Veiko Kukk <[hidden email]> 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 <[hidden email]>:
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








Reply | Threaded
Open this post in threaded view
|

Re: Avoiding TCP_REFRESH_HIT

Stephen Washburn
Ah… sorry about that.

Stephen

On Nov 23, 2017, at 10:22, Veiko Kukk <[hidden email]> 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 <[hidden email]>:
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


Stephen

On Nov 23, 2017, at 09:26, Veiko Kukk <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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.


David

On Thu, Nov 23, 2017 at 10:07 AM, Veiko Kukk <[hidden email]> 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 <[hidden email]>:
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








Reply | Threaded
Open this post in threaded view
|

Re: Avoiding TCP_REFRESH_HIT

Shu Kit Chan
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
<[hidden email]> wrote:

> Ah… sorry about that.
>
> Stephen
>
> On Nov 23, 2017, at 10:22, Veiko Kukk <[hidden email]> 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 <[hidden email]>:
>>
>> 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 <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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 <[hidden email]>:
>>>>
>>>> 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 <[hidden email]>
>>>> 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 <[hidden email]>:
>>>>>>
>>>>>> 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 <[hidden email]>
>>>>>> 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 <[hidden email]>:
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Avoiding TCP_REFRESH_HIT

Veiko Kukk
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 <[hidden email]>:
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
<[hidden email]> wrote:
> Ah… sorry about that.
>
> Stephen
>
> On Nov 23, 2017, at 10:22, Veiko Kukk <[hidden email]> 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 <[hidden email]>:
>>
>> 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 <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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 <[hidden email]>:
>>>>
>>>> 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 <[hidden email]>
>>>> 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 <[hidden email]>:
>>>>>>
>>>>>> 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 <[hidden email]>
>>>>>> 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 <[hidden email]>:
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Avoiding TCP_REFRESH_HIT

Veiko Kukk
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


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 <[hidden email]>:
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 <[hidden email]>:
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
<[hidden email]> wrote:
> Ah… sorry about that.
>
> Stephen
>
> On Nov 23, 2017, at 10:22, Veiko Kukk <[hidden email]> 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 <[hidden email]>:
>>
>> 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 <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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 <[hidden email]>:
>>>>
>>>> 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 <[hidden email]>
>>>> 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 <[hidden email]>:
>>>>>>
>>>>>> 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 <[hidden email]>
>>>>>> 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 <[hidden email]>:
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>