Re: mod-cache-requestor plan

[Parin Shah]

> - Cache freshness of an URL is checked on each hit to the URL. This runs
> the risk of allowing non-popular (but possibly expensive) URLs to expire
> without the chance to be refreshed.
>
> - Cache freshness is checked in an independant thread, which monitors the
> cached URLs for freshness at predetermined intervals, and updates them
> automatically and independantly of the frontend.
>
> Either way, it would be useful for mod_cache_requester to operate
> independantly of the cache serving requests, so that "cache freshening"
> doesn't slow down the frontend.
>
> I would vote for the second option - a "cache spider" that keeps it fresh.
>

- In this case, what would be the criteria to determine which pages should be refreshed and which should be left out. intitially I thought that all the pages - those are about to expire and have been requested - should be refreshed. but, if we consider keeping non-popular but expensive pages in the cache, in that case houw would te mod-c-requester would make the decision?


> Once mod_cache_requester has decided that a URL needs to be "freshened",
> all it needs to do is to make a subrequest to that URL setting the
> relevant Cache-Control headers to tell it to refresh the cache, and let
> the normal caching mechanism take it's course.

- hmm. this seems to be the most elegant solution.

> mod_cache_requester would probably be a submodule of mod_cache, using
> mod_cache provided hooks to query elements in the cache.

- considering that mod-cache-requester would be using some mod-cache's hooks to query the elements in the cache, would mod-cache-requester be still highly dependent on the platform (process vs threads)?

Thanks a lot for all this valuable information, Graham.

Parin.