[drupal-devel] CCK Node Caching Strategies

Gerhard Killesreiter killesreiter at physik.uni-freiburg.de
Sun Mar 6 07:25:30 UTC 2005



On Sat, 5 Mar 2005, Jonathan Chaffer wrote:

> The CCK implementation is going to require a resurrection of node
> caching,

Yay!

[...]

> I think we can do a bit better, though. By placing the node cache into
> a column in the node table, we can grab it at the same time as the node
> IDs. Then node_load() would look to see if the cache is present in the
> array presented to it, and if so use that rather than perform any
> queries at all.
>      1x query to fetch node IDs and cache for the ten nodes (10 results
> + deserialize)

So, what you will do is:
$result = db_query("SELECT ....");
while ($node = db_fetch_object($result)) {
  if($node->cache == '') {
    $node = node_load(array('nid' => $node->nid), 'no cache');
  }
  else {
    $node = unserialize($node->cache);
  }
}

?

> Note that we can use this method with the cache in the cache table as
> well, but that requires a JOIN using a CONCAT() in the ON clause, which
> seems risky, and involves direct knowledge of the cache table structure
> rather than using the cache API anyway.
>
> Any other ideas?

I've never liked the structure of the cache table much. It is a one size
fits all thing. Why not split is up?

cache_page   key: url
cache_filter key: md5 of string
cache_node   key: nid
cache_menu   key: uid
cache_misc   key: as now

This way we can keep the cache out of the node table (where it does not
really belong, IMHO).

I am pretty sure that SELECTs from smaller tables will also be faster.

The unknown number of entries of the filter cache makes me feel
uncomfortable.

Cheers,
	Gerhard




More information about the drupal-devel mailing list