Hello,

We're considering using ATS as a cache solution, but one of the features we
must have -- regex purge -- seems to be too slow for our purposes.

We read on [1] that the cache's in-RAM index does not store the URL:

"Data in HTTP headers cannot be examined without disk I/O. This includes
the original URL for the object. The cache key is not stored explicitly and
therefore cannot be reliably retrieved."

So when ATS receives a regex purge request, it must scan the disk for each
and every object in order to retrieve it's URL and compare it to the
pattern being searched. Is this assumption correct?

We're also assuming that this fact, that it must read from disc, is the
reason why regex purge is slow. We briefly looked the source code, and it
seems that ATS schedules a series of scans when it receives such a request,
and these scans are scheduled in a conservative way, probably to not slow
down the processing of other requests.

We searched the bug reports to see if there were reports concerning this.
We found issue TS-1323 [2] that seems to be about it, but we're not sure as
the issue's text was brief (it does not mention regex purge, but does
mention the fact that the object must be accessed).

Are our assumptions correct? If so, is there a plan to change the way it's
done (maybe have another index with the URLs, so the lookup would not have
to read from disk?)

[1]
https://trafficserver.readthedocs.org/en/latest/arch/cache/cache-arch.en.html
[2] https://issues.apache.org/jira/browse/TS-1323

Thanks in advance,
-- 
Acácio Centeno

Porto Alegre, Brasil + 55 51 3012 3005
Miami, USA + 1 305 704 8816

Quaisquer informações contidas neste e-mail e anexos podem ser
confidenciais e privilegiadas, protegidas por sigilo legal. Qualquer forma
de utilização deste documento depende de autorização do emissor, sujeito as
penalidades cabíveis.

Any information in this e-mail and attachments may be confidential and
privileged, protected by legal confidentiality. The use of this document
require authorization by the issuer, subject to penalties.

Reply via email to