How we handle purge: -Our cache is only disk based, so it is somewhat easier. -We have a hook that gets called after each cache store - ie, after we write a vary meta file, after we write a "real" meta file, after a datafile write (on close). -We also have a cache_get_info function that is exported (think curl_get_info) so that other modules can get info about cache objects (filenames, uri, sizes, etc.) -Our default "cache store" registers this post-store hook. It just writes the data out to a pipe - uri filename size expires\n -This piped program streams this info into a database (MySQL usually, as we had issues with SQLite) -Our cache manager is really just a fastcgi that uses the database to expire and purge cache objects.
In a vary situation, we will get 3 post-store's for the initial cache: -first is the "main" key for "main" meta file -second is the varied key for the "real" meta file (the one that has headers, etc.) -third is the varied key/file for the data So a simple sql query for "select file from my_table where url='/my/url'" will return all 3. (LIKE and regex's work as well.) We also can easily keep track of cache size (select sum(object_size) from my_table), oldest entries, etc. Subsequent requests for same uri with different vary will add 2 entries to the database - varied meta and data. The fastcgi and pipe are because we prototyped all of this in perl and never rewrote it because it all works fairly well. Also, we had a few issues with mysql client directly in Apache and the pipe was just easier... -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
