Current state

Every ZODB connection maintains a cache that keeps objects in memory to avoid unnecessary IO work.

All objects that are loaded within a transaction are put into the cache and are evicted from the cache at certain points (e.g. transaction boundaries) when cache minimization is performed. The currently implemented strategy for evicting objects is least recently used (LRU).

The size of the object cache is limited by the number of objects. This size is configurable per database.

Problems

Large applications have different usage patterns on objects so that the LRU strategy does not always fit those patterns effectively. Examples are:

• Applications with a variety of smaller and larger objects. The classical example of files stored as pdata constructs defeats the LRU caching strategy and potentially evicts heavily used (or even all) objects from the cache just to allow loading many smaller, infrequently used objects.
• Catalogs: Light-weight objects like brains might benefit from a higher priority of staying cached in comparison to other objects.

Historical solutions

To allow different cache settings developers resorted to splitting their database into multiple smaller databases. Each database then is responsible for maintaining its own cache for the objects stored in it. An example for this is to create a separate database for catalogs and one for the actual application objects.

Creating separate databases for separating caches is a non-ideal solution as the storage layout becomes dependent on the caching strategies and blocks the use of separate databases for other, potentially orthogonal, uses.

Proposed solution

I propose to:

1. modify the ZODB to allow different cache implementations to be used, and
2. implement a cache that performs an object classification using a configurable strategy

Risks

• Storing and loading objects from and to the caches requires more computational overhead. Complex classification strategies might become unforeseen bottlenecks.
• Increasing complexity might make the system more fragile.

TODO

• Determine package name for the classifying cache. Optionally think about making this a core functionality.
• Provide default classification implementations that fit a few regularly used patterns: a Zope 2 database, a Zope 2/CMF database, ... ?
• Prepare an analysis strategy to use a live site to compare the caches' efficiency. The analysis should result in a comparison of the amount of loads that are performed using the different caches. (Using cacti or some other graphing tool, isn't there some information source within Zope for this anyway?)

Future enhancements

• Allow the classes to use different cache implementations themselves, e.g. one that uses a different way of evicting the cache than LRU.
• Provide a monitoring tool to show the status of the cache in detail for every class (objects in class, size of class), maybe including the details of how many objects of which Python class are in each cache class. (Eventually this is just an extension to getCacheDetail and getCacheExtremeDetail)
• Provide a monitoring tool that logs object loads, stores and releases. (Stating the time, the action, the oid, the object class and the cache class). (Eviction might be pretty hard as it happens invisibly for us.)

Sensible defaults --tseaver, Mon, 20 Aug 2007 17:43:01 +0000 reply

• Pdata objects should never be cached. although the root "file" objects can be.
• BTree?-related objects (buckets, sets, trees) and brains objects should be cached in the same class.

Configuration coherence --tseaver, Mon, 20 Aug 2007 17:49:59 +0000 reply

There needs to be an easy way to specify classifications in the same place that the cache size is set. Either:

• Define the classification model using ZConfig?, something like:

  <classifyingcache>
    <class "catalog">
    </class>
    <class "pdata">