On 6/26/13 10:04 AM, Réjean Bouchard wrote:
Maybe my explanations are not clear enough.
We always have a lot of images in cache. That's why we have to do a regex
search using the webUI ( http://exemple_domain/cache/lookup_regex_form ).
From that result page we obtain after the search, it's impossible to do a
URL lookup by clicking the name of the file or delete a file by checking a
box and clicking the "delete" button at the end of the page. We not
necessary know the full name of all of images. That's why we want to use
the regex search result page.
Fwiw, what I would do, if it was me, would be to log all client request
URLs, and produce a little DB (anything will do), and then apply the regex
to that list of URL when you need to purge based on regexes. Then simply
PURGE those URLs that matches.
The "problem" with the ATS cache is that it consumes and stores minimal
amounts of RAM (10 bytes per cache object). This is certainly by design, to
allow for very large caches. Adding additional information, such as lists of
active URLs, is not part of the design (and hopefully never will be), for
these special cases, do special things outside of the cache :).
One interesting idea that GoDaddy implements in their CDN is to create
generation IDs for certain content. They do it per domain, but you do it
based on e.g. a prefix of the URL path. It allows for instant (O(1)) cache
invalidation of large portions of the cache. This requires a custom plugin,
of course.
-- Leif
