Elysia Cron is a perfect module and indeed it would be possible to re-write all cache refreshes as cron hooks and then configure them to run at different times.
Still, I look for a more generic solution (consecutive refreshes of any number of caches rather than having to set a time for each) and possibly somehow using Drupal's cache (hm, perhaps using cache_set with CACHE_PERMANENT and then, at x seconds after it was created consider it expired, but refresh maximum one cache per request?) <http://www.vacilando.org/> On Mon, Oct 18, 2010 at 12:59, Chris Skene <[email protected]> wrote: > 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). > > <http://www.vacilando.org/> > > > > On Mon, Oct 18, 2010 at 12:25, Chris Skene <[email protected]> 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 >> >> >> >> > >
