On 3/7/07, Metzler, David <metzlerd@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.