[development] Refresh rather than re-create D6 cache

[Chris Skene]

Would something like Elysia Cron solve the problem...

http://drupal.org/project/elysia_cron

It has some advanced cron control which can manage long requests, as well as disable or change the timing on different cron hooks.

On 18/10/2010, at 9:41 PM, Tomáš Fülöpp (vacilando.org) wrote:

> Not all caches would have to be re-populated at the same time. 
> 
> Currently, if many or all caches get empty, they need to be re-populated on request, extending the script execution. On a busier site other requests are waiting because the first request is still not finished re-populating caches. Eventually, Apache's maximum number of connections may be reached. 
> 
> In the scenario I am considering, expired caches would not be emptied, so they would continue serving (slightly older) data fast, and they would be refreshed gradually (e.g. one cache per request). 
> 
> 
> 
> 
> 
> On Mon, Oct 18, 2010 at 12:25, Chris Skene <chris at xtfer.com> wrote:
> What would be the practical difference between emptying and recreating a cache, and refreshing it?
> 
> On 18/10/2010, at 9:22 PM, Tomáš Fülöpp (vacilando.org) wrote:
> 
>> Hi,
>> 
>> In D6, after all caches are cleared, or after a lot of them expire and get emptied by cron, the server load spikes seriously because all such caches need to be re-populated.
>> 
>> Since this happens more and more on sites I work on, I have been thinking about using another approach in my modules, in the sense that caches would be refreshed rather than cleared and re-populated. Each cache refresh would run depending on e.g. a simple variable storing last time stamp of any other cache refresh.
>> 
>> This would assure that a) all cached values would be available at all times, b) caches would never be re-calculated all at the (near) same time.
>> 
>> I am about to write logic for this, but wanted to first check with others in the list -- perhaps some of you know or can point to an elegant solution that already exists.
>> 
>> Thanks!
>> 
>> vacilando
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20101018/71401485/attachment.html