[Zope-dev] Do I really understanding caching?

[Jim Fulton]

Andy McKay wrote:
> 
> We have been looking at caching in Zope as a way of tweaking performance.
> Heres an example of what I think happens:
> 
> - Supposing I have a 1,000 object catalog. If one person changes an catalog
> aware object, that instance of the catalog will be pulled out of the ZODB
> and changed. It will then be written to the ZODB. That last copy will stay
> in the cache for as long as the "Cache Parameters" are set to allow.
> 
> - If somebody changes another catalog aware object, that will repeat the
> above process.
> 
> - However simply accessing the catalog (no changes) will pull the object
> from the cache.
> 
> - What would be really nice is if the object only got written to the cache
> when it is no longer used, that way every time the catalog changed it didnt
> write to ZODB instead it changed the cached version. Of course that does
> bring up the recovering from disaster problem.
> 
> So do I understand it correctly?

Not exactly.  Have you seen the ZODB paper?

  http://www.zope.org/Members/jim/Info/IPC8/ZODB3

You can think of the normal ZODB cache as being a tool that
manages the objects in memory.  Whenever an object has been
accessed, it is in the cache. The cache, together with the
database are responsible for moving objects, and their state
in and out of memory. An object can be in serveral in memory 
states. Two that are of interest, from a caching perspective, 
are the "ghost" state and the up-to-date state.  The up-to-date
state is a state in which the object and it's state are loaded.
In the ghost state, the object is in memory, but it has now state.

The cache manager tries to release an object's state and 
remove the object from memory when it is not used.  An object's
state is released when it hasn't been accessed in a long time.
It can be removed when no other objects (not counting the
cache itself) refer to it.

Note that the cache parameters are only guides for an algorithm
that is somewhat adaptive and a bit more complicated than
the parameters suggest. For example, the target cache size is a 
target, not a limit. The cache sizes are usually mich higher than
the target.

Another thing to be aware of is that large objects are generally 
designed to spread their state over many subobjects so that
they can make effective use of the cache.  A catalog may have hundreds
of sub-objects, only a small fraction of which are kept in memory
at a time.

Jim

--
Jim Fulton           mailto:jim@digicool.com
Technical Director   (888) 344-4332              Python Powered!
Digital Creations    http://www.digicool.com     http://www.python.org

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.