httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Parin Shah <>
Subject Re: mod-cache-requestor plan
Date Tue, 12 Jul 2005 03:48:36 GMT
> - 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 

> 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.


View raw message