<br><br><div><span class="gmail_quote">On 3/7/07, <b class="gmail_sendername">Metzler, David</b> <<a href="mailto:metzlerd@evergreen.edu">metzlerd@evergreen.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>If you're talking about object caching where in 90% of the cases the<br>objects live in the database, I wonder whether this kind of caching<br>would have a better payoff than just increasing the memory caching done
<br>by the DB engine (mysql,etc). It doesn't strike me as a big payoff for<br>the code that it would take too achieve.</blockquote><div><br>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.
<br><br>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)
<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;">I'd recommend general caching drupal caching API's should be restricted
<br>to "rendered" objects, such as the output of a block, a view, or a menu.<br>Then you save the expensive rendering process. If you're just talking<br>about object data, let the database engines do the caching.
</blockquote><div><br>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.
<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;">Of course it does make sense to cache XMLRPC call results and other<br>expensive data gets.
<br><br>It seems really odd to talk about caching nodes in a database, when<br>nodes and users are in a database to begin with?</blockquote><div><br>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.
<br><br><br><br></div></div><br>-- <br><br>Steve Rude<br>Lead Web Developer<br><br> 800-618-8777phone / 858-225-0479 fax<br> <a href="http://www.achieveinternet.com">www.achieveinternet.com</a><br> <a href="mailto:steve@achieveinternet.com">
steve@achieveinternet.com</a><br><br> Achieve Internet is a Division of<br> Web Page Maintenance, Inc.