<div><div>All-<br><br>In our large Savannah project (<a href="http://new.savannahnow.com">http://new.savannahnow.com</a>) we have been running some tests with both Jeremy's file-based cache and with object-based caching. Some notes.
<br><br> 1) I like the filecache patch and have privately sent Jeremy some 4.6 code that remove tthe *wildcard delete barrier to its usage. The solution is to create unique folders for each cache type (variable, filter, page, et. al.) and then purge that folder when sending cache_clear_all('filter', TRUE). Happy to share the code with others.
<br><br> 2) I was under some internal pressure to reduce the sheer volume of db queries on a page. Object caching allows that. In production right now, we cache the following objects:<br> <br> $node<br> $user<br> $block
<br> $profile<br><br>In the cases of $node, $profile $user, we intercept the _load() function and check to see if a cached version of the object exists. It it does, we load it and skip entirely the hook_user hook_nodeapi hook_load steps of the code. If it doesn't exist, we load the object normally and then cache the result.
<br><br>In order to make this work, we also have to know when to flush the individual object cache when a user makes a change. We flush on node_edit, block_save and user_edit, for example.<br><br>(Apologies for not having good benchmarks, but if memory serves, it increased our page load speed about 15-20% and took 60-70% of the load off MySQL). In the case of a user page, it cuts our queries from around 140 to 25 or fewer after the initial page view.
<br><br>Some problems / issues / goals going forward:<br><br>1) Definitely a cache API. Many contrib modules (and some 4.6 core) use cache_clear_all() far too loosely. As a result, we flush the cache far too often. <br>
<br>1a) In fact, the only way to clear a cache of any sort is with cache_clear_all($cid) or cache_clear_all($type, $wildcard = TRUE) or cache_clear_all(). We need more than one function in order to be more clear about what the code needs to accomplish. The
block.module, for instance, runs cache_clear_all() on 3 occassions. But it never really intends to clear the entire cache, does it?<br> <br>2) I'm not sure that I have properly identified all the times to clear the object cache.
<br><br>3) Some of this is made unnecessary by the fastcache or page cache, but an object cache applies to logged in users as well. For that reason, even caching the $user object would be a benefit.<br><br>4) I am more than happy to contribute notes and code to getting this into
4.8. The work I've done is all in 4.6.x, but the approach can apply to CVS.<br><br>--<br>Ken Rickard<br>agentrickard <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Message: 5<br>Date: Wed, 12 Jul 2006 10:21:49 +0200<br>From: Dries Buytaert <<a href="mailto:dries.buytaert@gmail.com">dries.buytaert@gmail.com</a>><br>Subject: Re: [development] Caching, caching, caching...<br>To:
<a href="mailto:development@drupal.org">development@drupal.org</a><br>Message-ID: <<a href="mailto:DB3DEF7E-FA41-4AD3-A210-C177CA4B2853@gmail.com">DB3DEF7E-FA41-4AD3-A210-C177CA4B2853@gmail.com</a>><br>Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
<br><br><br>On 12 Jul 2006, at 00:01, Gerhard Killesreiter wrote:<br>> Now the question is if we want to go down this road. To properly<br>> invalidate the cache requires to implement all sorts of hooks (forum<br>> module needs _comment and _user for example) which you would not need
<br>> otherwise. This complicates the code quite a bit.<br><br>Personally, I'd not optimize with MySQL's query cache in mind. If<br>the folks at MySQL improve their query cache implementation, our<br>efforts might have been moot. I'd focus my energy on high-level
<br>improvements, rather than low-level improvements. That is, I'd focus<br>architectural changes that reduce the number of SQL queries or that<br>simplify complex queries (eg. less joins). For example, the node<br>table and node_comment_statistics table have a one-on-one relation
<br>and could potentially be merged. I'm not sure what it would buy us,<br>but it might be worth it.<br><br>Maybe we should run the modified devel.module on <a href="http://drupal.org">drupal.org</a> to see<br>what the most expensive queries are? You know, accumulate results
<br>over multiple page views. Do we have recent data query data from<br><a href="http://drupal.org">drupal.org</a>? Let's start by identifying some key bottlenecks.<br><br>--<br>Dries Buytaert :: <a href="http://www.buytaert.net/">
http://www.buytaert.net/</a><br><br><br><br>------------------------------<br><br>--<br>[ Drupal development list | <a href="http://lists.drupal.org/">http://lists.drupal.org/</a> ]<br><br>End of development Digest, Vol 43, Issue 38
<br>*******************************************<br></blockquote></div><br>