[development] Object caching (was: memcache)

Steve Rude steve at achieveinternet.com
Wed Mar 7 18:17:18 UTC 2007

On 3/7/07, Metzler, David <metzlerd at evergreen.edu> wrote:
> If you're talking about object caching where in 90% of the cases the
> objects live in the database, I wonder whether this kind of caching
> would have a better payoff than just increasing the memory caching done
> by the DB engine (mysql,etc). It doesn't strike me as a big payoff for
> the code that it would take too achieve.

The main issue here is that building the node object by invoking a lot of
expensive select and joins is a real slowdown in my testing.  Not to mention
that real world query caching does not get you very far on a heavily
trafficked website.

The other part of this that is missing is that in a multi-server environment
using memcached as a shared cache allows you to only need to build the node
objects once per farm of servers before it is cleared or rebuilt based on
max life.  With file based caching you have to do it on every server.
(Obviously you could do this on a NFS'd file system, but that would negate a
lot of the speed)

I'd recommend general caching drupal caching API's should be restricted
> to "rendered" objects, such as the output of a block, a view, or a menu.
> Then you save the expensive rendering process. If you're just talking
> about object data, let the database engines do the caching.

I would agree that these would are good places to cache as well, but using
eAccelerator or APC you can significantly speed up the time it takes php to
build the rendered output from the object.  I haven't seen the rendering to
be all that significant.  I still need to do some more testing however.

Of course it does make sense to cache XMLRPC call results and other
> expensive data gets.
> It seems really odd to talk about caching nodes in a database, when
> nodes and users are in a database to begin with?

As Andy pointed out already (sorry I was late to jump on this), nodes don't
live in one table.  The biggest problem in addition to the other tables that
get queried to build the nodes, is the node > node_revisions join that
happens.  In our experience with an active site with user contributed data,
the node_revisions table can get big very fast.


Steve Rude
Lead Web Developer

    800-618-8777phone / 858-225-0479 fax
    steve at achieveinternet.com

    Achieve Internet is a Division of
    Web Page Maintenance, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070307/1d6df245/attachment-0001.htm 

More information about the development mailing list