This mail from Jim at this list a couple of years ago was stocked full
of nice tips:

In particular:

- Yes, use persistent cache. Recent versions are reliable. Make it as
large as resonable (e.g at most the size of your packed database, at
least the size of objects that you want to be around after a restart).

- Consider using zc.zlibstorage to compress the data that's stored in ZODB

- set drop-cache-rather-verify to true on the client (avoid long
restart time where your client is revalidating the ZEO cache)

- set invalidation-age on the server to at least an hour or two so
  that you deal with being disconnected from the storage server for a
  reasonable period of time without having to verify.



On Thu, Mar 7, 2013 at 3:54 PM, Roché Compaan
<> wrote:
> We have a setup that is running just fine when the caches are warm but
> it takes several minutes after a restart before the cache warms up.
> As per usual, big catalog indexes seem to be the problem.
> I was wondering about two things. Firstly, in 2011 in this thread
> about zeo.memcache, Shane said that he could adapt the caching code in
> RelStorage for ZEO. Shane do you still plan to do this? Do you think
> an instance can restart without having to reload most objects into the
> cache?
> Secondly, I was wondering to what extent using persistent caches can
> improve cache warm up time and if persistent caches are usable or not,
> given that at various times in the past, it was recommended that one
> try and avoid them.
> --
> Roché Compaan
> Upfront Systems         
> _______________________________________________
> For more information about ZODB, see
> ZODB-Dev mailing list  -
For more information about ZODB, see

ZODB-Dev mailing list  -

Reply via email to