[development] Object Caching in DRUPAL-7?

[Josh Koenig]

Thanks for the pointers on where I need to get up to speed!

In terms of what I mean by a "global object caching strategy," ideally that
means the same code, but at a minimum parallel APIs or methods. Most
importantly it should be easy for savvy developers to follow "the Drupal
way."

Ultimately this is a design pattern thing, where we stop thinking of
everything as necessarily coming from a database, and start thinking in
terms of using the database as a highly efficient method for pulling up
lists of IDs, and then loading the objects that are germane. My initial
thoughts are here:

http://groups.drupal.org/node/19385

Without object caching this is potentially expensive: think of the
difference between a simple view built around specific fields vs one that
calls node_load() for each resulting item. However, once you've got your
nodes in a memory cloud, it's actually quite a lot faster.

Moreover, this follows emerging best-practices for high availablility and
scalability. E.g.:

http://dev.mysql.com/doc/refman/5.1/en/ha-memcached.html

As memcached becomes a commodity service -- e.g. it's trivial to roll out
with the latest Debian and CentOS releases -- the upside of having the
community put collective brainpower into the best way to utilize these tools
(abd bake support into core) is huge.

cheers
-josh

On Sun, Feb 22, 2009 at 12:29 PM, Nathaniel Catchpole <
catch56 at googlemail.com> wrote:

> There's a patch for node_load() here - http://drupal.org/node/111127 - has
> been sitting at RTBC for weeks though and just gone stale again.
>
> Since terms, users (hopefully, soon) etc. have almost exactly the same code
> for loading now, it'd be easy to add the same pattern there too, and I was
> thinking about trying that if node_load() gets in.
>
> The new core field API also allows objects to declare themselves as already
> cached - so the field cache is skipped for those objects and we save filling
> up memcache bins with the same stuff, so no issues there.
>
> However I'm not sure what you mean by a global object caching strategy -
> actually the same code? Or just parallel APIs? Nedjo Rogers has a patch for
> the former at http://drupal.org/node/365899 - adding cache_set/get to it
> wouldn't be hard at all (at least when loading by IDs, which is all we need
> really). Although I'd be tempted to add the caching in separate patches then
> unify it all later rather than trying to do both at once.
>
> +1, anyway.
>
> Nat
>
>
>
>
>>
>> Josh Koenig wrote:
>>
>>> Greetings,
>>>
>>> I'd like to take the community's temperature on developing a global
>>> object caching strategy for drupal core 7.0. In effect, this would mean
>>> pulling the functionality of advcache module into core, though the code
>>> would doubtless be a bit different.
>>>
>>> This has been previously discussed by Robert Douglass and Steve Rude, and
>>> I think both the short-term and strategic value here is clear. As memcached
>>> permeates the collective consciousness of the web-development community, and
>>> as "cloud" computing becomes more and more prevalent, best practices in
>>> architecture increasingly point towards caching full objects whenever
>>> possible.
>>>
>>> This also fits well with Drupal's existing architecture. There are great
>>> functional points (e.g. node_load()) to mount this functionality.
>>>
>>> I'm certain I'm not the only one thinking along these lines. Anyone want
>>> to throw out their ideas?
>>>
>>> cheers
>>> -josh
>>>
>>>
>


-- 
--------------------
Josh Koenig, Partner & CTO
http://www.chapterthree.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090222/79f24a72/attachment-0001.htm