An alternative solution would be to implement an additional layer
similar to how Varnish provides "ban lists". The name is a little
misleading and refers to banning content from being served from the
cache. In a nutshell, Varnish keeps a list of bans which can be regexes.
Each cache hit is then checked against all _newer_ bans and reconsidered
as a miss in case of match.
Additionally a ban-lurker thread is scanning the cache in the background
looking for objects which match bans and evict them. It can help keep
the ban list at a reasonable size.
You can read more about it in Varnish tutorial:
https://www.varnish-cache.org/docs/3.0/tutorial/purging.html#bans
This method has it drawbacks, particularly if there is a lot of
long-lived objects in the cache. Still, it gives more flexibility to admins.
Best regards,
Tomasz Kuzemko
tom...@kuzemko.net
W dniu 20.03.2014 20:48, Alan M. Carroll pisze:
Thursday, March 20, 2014, 1:28:45 PM, you wrote:
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?
Yes.
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?)
We are working on a general upgrade to the cache API to enable plugins to do
more, but that's not going to be done in the near future and even then it's
very unlikely we will change this aspect. The problem is this increases the
memory requirements massively and currently we have people who are having
problems with sufficient ram for their (multi-hundred terabyte) caches.
