[ZODB-Dev] Slow Zeo load times after upgrade to ZODB 3.4

[Erik A. Dahl]

> When an application using ZEO tries to load a persistent object:
>
> 1. It first looks in the ZODB cache.
>
> 2. If that's a miss (the object is not in the ZODB cache),
>    it consults the ZEO cache.
>
> 3. If that's a miss too (the object isn't in the ZEO cache either),
>    it asks the ZEO server for the object's state.
>
> So wrt the ZODB cache, the ZEO cache is a second-level cache.  The  
> ZODB
> cache has a least-recently used replacement policy, and the hope is  
> that
> not-recently-used objects that have been booted from the ZODB cache  
> can
> usually still be found in the ZEO cache, saving the usually much  
> greater
> expense of fetching state from the ZEO server over the network.
>
This is very helpful thanks!

In my setup I have zeo and zope on the same box.  I'm using zeo  
because several data loader applications are populating the  
database.  I wan't these to use the same db as zope so I have been  
using the same config file (they aren't zope instances just daemons  
that do the import Zope2; app=Zope2.app() thing).  Until I tried to  
turn on persistent caching this has never been an issue (but I  
understand now that its most likely not a good idea).

Because everything is on the same box I don't think I'm getting much  
by having the ZEO cache, but maybe its quicker to load from the cache  
then to use the zeo protocol to pull objects from the database on the  
same box?  I and there is the issue of cache maintenance at startup.   
I will play around with it a bit now that I understand the  
relationships of the caches (and how to use the persistent caching  
properly!)

-EAD