Hi, Ben Coburn wrote: >>> On Apr 3, 2006, at 4:35 PM, Mario Emmenlauer wrote: >> I might be totally wrong, though, because of three reasons: >> - I'm not sure if my cache is configured correctly >> - I'm not sure if my hacking was correct >> - utf8_substr() is called to estimate the page-length, I'm not sure >> if that is always done (no matter if the page is cached or not), in >> which case caching again had nothing to do with it. >> > > If the cache is working there should be a bunch of folders and files > named stuff like "f/f7c88db2e521b95b1c4fa5aa829f8504.feed" under your > "data/cache/" directory. Certainly you did not forget to make the cache > directory writable by the web server? Ok, forget what I wrote about the cache. I just re-implemented the tiny hack, and it turns out that the problem was as such: When feed.php gets called with several large pages, utf8_substr() times out and crashes apache. Thus the cache isn't updated, so that the next call to feed.php uses utf8_substr() again. Since there will be fewer resources available with every call, php is more likely to timeout until eventually utf8_substr() is used on every update. Now at 7 am in the morning, the load on the server is quite low, and the caching works correctly. I'm sorry for the misleading trail, once the cache is generated it works perfectly! :-/ Cheers, Mario -- DokuWiki mailing list - more info at http://wiki.splitbrain.org/wiki:mailinglist