unexpected high amount of Cold lookups

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

unexpected high amount of Cold lookups

ezko
Hi,
i'm getting a pretty high number of
proxy.process.http.transaction_counts.miss_cold which I don't expect.
All my cached objects are set with an explicit Cache-Control max-age , so
when they expire , if a new copy is retrieved from the origin , it has to be
new.
How can i debug this issue ?
thanks in advance.
EZ



--
Sent from: http://apache-traffic-server.24303.n7.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: unexpected high amount of Cold lookups

Miles Libbey
On Sun, Dec 10, 2017 at 8:56 AM, ezko <[hidden email]> wrote:
> Hi,
> i'm getting a pretty high number of
> proxy.process.http.transaction_counts.miss_cold which I don't expect.
> All my cached objects are set with an explicit Cache-Control max-age , so
> when they expire , if a new copy is retrieved from the origin , it has to be
> new.
> How can i debug this issue ?

Some questions I would be asking myself:
- Is my cache big enough to support my working set size?
proxy.process.cache.wrap_count tells you how often the cache has
wrapped since the last restart.
- When I look at the requested urls and their cache status, Do I get
any hints as to why there are misses? (For instance, perhaps there are
random query strings in the requests making ATS think they are novel
objects).
- Do my objects Vary on reasonable headers (eg, *not* user-agent,
cookie, ...)? Perhaps there are too many variants?
- Are there POSTs or other http verbs that would invalidate the cached object?

miles
Reply | Threaded
Open this post in threaded view
|

Re: unexpected high amount of Cold lookups

ezko
thanks for the suggestion miles.

i checked the cache as you suggested. I think its OK. There are no
unexpected query strings , or other noticeable object variations.
proxy.process.cache.wrap_count seems low , and I don't see any non-GET
verbs.

I suspect there is something wrong with the way Cache-control max-age header
is set.
If for example I set Cache-control max-age  to 4 seconds , when ATS caches
the object , how does it decide when the object is expired ? I assumed it
will simply expire the object after 4 seconds. Is that true ? , or are there
any other affecting factors ?

looking into the diag.log - can I spot ATS making a COLD decision ?

thanks in advance.
 
 



--
Sent from: http://apache-traffic-server.24303.n7.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: unexpected high amount of Cold lookups

Miles Libbey
On Tue, Dec 12, 2017 at 2:46 AM, ezko <[hidden email]> wrote:

> thanks for the suggestion miles.
>
> i checked the cache as you suggested. I think its OK. There are no
> unexpected query strings , or other noticeable object variations.
> proxy.process.cache.wrap_count seems low , and I don't see any non-GET
> verbs.
>
> I suspect there is something wrong with the way Cache-control max-age header
> is set.
> If for example I set Cache-control max-age  to 4 seconds , when ATS caches
> the object , how does it decide when the object is expired ? I assumed it
> will simply expire the object after 4 seconds. Is that true ? , or are there
> any other affecting factors ?

The main other factor I can think of is around Vary:. ATS will store
(up to 5 by default) variants. So, when the request comes in, ATS
picks the variant that best matches the request. If the object varies
on user-agent (of which there are zillions), there is likely not going
to be a match.

> looking into the diag.log - can I spot ATS making a COLD decision ?

I'm not sure. We use cacheStatus=%<chm> in our logs
https://docs.trafficserver.apache.org/en/7.1.x/admin-guide/logging/formatting.en.html

> thanks in advance.
>
>
>
>
>
> --
> Sent from: http://apache-traffic-server.24303.n7.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: unexpected high amount of Cold lookups

ezko
thanks miles,
i actually found in the cache 2 variants (different Accept-Encoding:)
 


Miles Libbey wrote
> On Tue, Dec 12, 2017 at 2:46 AM, ezko &lt;

> erez.koler@

> &gt; wrote:
>> thanks for the suggestion miles.
>>
>> i checked the cache as you suggested. I think its OK. There are no
>> unexpected query strings , or other noticeable object variations.
>> proxy.process.cache.wrap_count seems low , and I don't see any non-GET
>> verbs.
>>
>> I suspect there is something wrong with the way Cache-control max-age
>> header
>> is set.
>> If for example I set Cache-control max-age  to 4 seconds , when ATS
>> caches
>> the object , how does it decide when the object is expired ? I assumed it
>> will simply expire the object after 4 seconds. Is that true ? , or are
>> there
>> any other affecting factors ?
>
> The main other factor I can think of is around Vary:. ATS will store
> (up to 5 by default) variants. So, when the request comes in, ATS
> picks the variant that best matches the request. If the object varies
> on user-agent (of which there are zillions), there is likely not going
> to be a match.
>
>> looking into the diag.log - can I spot ATS making a COLD decision ?
>
> I'm not sure. We use cacheStatus=%
> <chm>
>  in our logs
> https://docs.trafficserver.apache.org/en/7.1.x/admin-guide/logging/formatting.en.html
>
>> thanks in advance.
>>
>>
>>
>>
>>
>> --
>> Sent from: http://apache-traffic-server.24303.n7.nabble.com/





--
Sent from: http://apache-traffic-server.24303.n7.nabble.com/