ATS 6.2.1 + cache read

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

ATS 6.2.1 + cache read

Jeremy Payne
Question.. Is there a known issue with ATS 6.2.1(or any version),
where if ATS can't read from
cache fast enough for a given object, ATS simply sends an IMS to the
origin, instead of waiting for a response from the cache lookup ?

I am noticing that if multiple requests fall in the same second for a
given object, that ATS gives up
trying to read from cache, and simply sends an IMS to the origin.

Known issue? Or possible PEBCAK error again ?
Reply | Threaded
Open this post in threaded view
|

Re: ATS 6.2.1 + cache read

Alan Carroll-2
I think this is a known issue for a long time. What's happening is the requests are trying to get the write lock on the object and failing, which results in giving up and going direct to origin. There might be a collapsed forwarding plugin which sort of mitigates this. There is on going work on fixing it but that's not ready for production yet.

On Fri, Sep 22, 2017 at 5:45 PM, Jeremy Payne <[hidden email]> wrote:
Question.. Is there a known issue with ATS 6.2.1(or any version),
where if ATS can't read from
cache fast enough for a given object, ATS simply sends an IMS to the
origin, instead of waiting for a response from the cache lookup ?

I am noticing that if multiple requests fall in the same second for a
given object, that ATS gives up
trying to read from cache, and simply sends an IMS to the origin.

Known issue? Or possible PEBCAK error again ?

Reply | Threaded
Open this post in threaded view
|

Re: ATS 6.2.1 + cache read

Leif Hedstrom
Hmmm but there are settings for this, overridable, to retry the cache operation some number of times. You will want read-while-writer too.

— Leif 

On Sep 22, 2017, at 17:15, Alan Carroll <[hidden email]> wrote:

I think this is a known issue for a long time. What's happening is the requests are trying to get the write lock on the object and failing, which results in giving up and going direct to origin. There might be a collapsed forwarding plugin which sort of mitigates this. There is on going work on fixing it but that's not ready for production yet.

On Fri, Sep 22, 2017 at 5:45 PM, Jeremy Payne <[hidden email]> wrote:
Question.. Is there a known issue with ATS 6.2.1(or any version),
where if ATS can't read from
cache fast enough for a given object, ATS simply sends an IMS to the
origin, instead of waiting for a response from the cache lookup ?

I am noticing that if multiple requests fall in the same second for a
given object, that ATS gives up
trying to read from cache, and simply sends an IMS to the origin.

Known issue? Or possible PEBCAK error again ?

Reply | Threaded
Open this post in threaded view
|

Re: ATS 6.2.1 + cache read

Steven Hunter
The new w7pre hds overrides operations and shuts down memories overload capabilities...

On Sat, Sep 23, 2017 at 3:36 PM, Leif Hedstrom <[hidden email]> wrote:
Hmmm but there are settings for this, overridable, to retry the cache operation some number of times. You will want read-while-writer too.

— Leif 

On Sep 22, 2017, at 17:15, Alan Carroll <[hidden email]> wrote:

I think this is a known issue for a long time. What's happening is the requests are trying to get the write lock on the object and failing, which results in giving up and going direct to origin. There might be a collapsed forwarding plugin which sort of mitigates this. There is on going work on fixing it but that's not ready for production yet.

On Fri, Sep 22, 2017 at 5:45 PM, Jeremy Payne <[hidden email]> wrote:
Question.. Is there a known issue with ATS 6.2.1(or any version),
where if ATS can't read from
cache fast enough for a given object, ATS simply sends an IMS to the
origin, instead of waiting for a response from the cache lookup ?

I am noticing that if multiple requests fall in the same second for a
given object, that ATS gives up
trying to read from cache, and simply sends an IMS to the origin.

Known issue? Or possible PEBCAK error again ?