[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