Discussion:
ATS 6.2.1 + cache read
Jeremy Payne
2017-09-22 22:45:56 UTC
Permalink
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 ?
Alan Carroll
2017-09-22 23:15:32 UTC
Permalink
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.
Post by 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 ?
Leif Hedstrom
2017-09-23 22:36:14 UTC
Permalink
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
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.
Post by 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 ?
Steven Hunter
2017-10-06 00:37:23 UTC
Permalink
The new w7pre hds overrides operations and shuts down memories overload
capabilities...
Post by 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
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.
Post by 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 ?
Continue reading on narkive:
Loading...