<font size="2">Yes, Larry, I did experiment with that approach as well. It allows caches to expire at different times, but a) you need to keep some sort of approximate overview about the various expiration delays you&#39;re setting (so that they don&#39;t have much chance happening at the same time) and b) whenever such cache happens to expire, it still gets deleted at cron and then will have to be re-calculated during the precious time of page request.<br>

<br>Currently I am thinking about the following approach - crude pseudo code:<br><br>// Make sure no other cache has been started over defined period<br></font><font size="2">* set buffer period between cache refreshes $cbuffer = 15 seconds<br>


</font><font size="2">* if ( (time()-$lastcacherun) &gt; $cbuffer )<br><br>// Check if the cache at hand has expired<br>* Set some cache life time $clife<br>* SELECT `created` FROM `cache` where `cid` = &#39;cachedobjectname&#39;<br>

* if ( (time()-$created) &gt; $clife )<br><br></font><font size="2">// Refresh the expired cache<br></font><font size="2">* </font><font size="2">$lastcacherun = time()</font><br>* recreate cachedobjectname <br style="color: rgb(102, 102, 102);">

* DELETE FROM `cache` WHERE cid = &#39;cachedobjectname&#39;<br>* cache cachedobjectname using cache_set  with CACHE_PERMANENT <br>
<br style="color: rgb(102, 102, 102);">What do you think?<br><br><br><br><br>
<br><br><div class="gmail_quote">On Mon, Oct 18, 2010 at 14:34, <a href="mailto:larry@garfieldtech.com">larry@garfieldtech.com</a> <span dir="ltr">&lt;<a href="mailto:larry@garfieldtech.com">larry@garfieldtech.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Just to make sure, have you tried using the minimum cache lifetime on the performance page?  It essentially says that a cache record will always last at least that long, even if a clear is requested for it. That&#39;s your first step if you&#39;re finding some caches clearing too frequently (especially the expensive filter and page caches).<br>


<br>
--Larry Garfield<div><div></div><div class="h5"><br>
<br>
On 10/18/10 5:22 AM, Tomáš Fülöpp (<a href="http://vacilando.org" target="_blank">vacilando.org</a>) wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br>
<br>
In D6, after all caches are cleared, or after a lot of them expire and<br>
get emptied by cron, the server load spikes seriously because all such<br>
caches need to be re-populated.<br>
<br>
Since this happens more and more on sites I work on, I have been<br>
thinking about using another approach in my modules, in the sense that<br>
caches would be /refreshed/ rather than cleared and re-populated. Each<br>
cache refresh would run depending on e.g. a simple variable storing last<br>
time stamp of any other cache refresh.<br>
<br>
This would assure that a) all cached values would be available at all<br>
times, b) caches would never be re-calculated all at the (near) same time.<br>
<br>
I am about to write logic for this, but wanted to first check with<br>
others in the list -- perhaps some of you know or can point to an<br>
elegant solution that already exists.<br>
<br>
Thanks!<br>
<br>
vacilando<br>
<br>
<br>
</blockquote>
</div></div></blockquote></div><br>