I was having this same issue. Persistent caching helped a little bit but not
too much. I didn't end up implementing this but ultimately the best thing
to do
seemed to be to have a different server with a different zodb that only
handles indexing. That way it will never restart and lose its cache. The
downside
is you have to figure out a way to communicate between the two servers.
Maybe a clean way would be to use the multiprocessing module somehow.

On Thu, Mar 7, 2013 at 1:54 PM, Roché Compaan <ro...@upfrontsystems.co.za>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
> https://mail.zope.org/pipermail/zodb-dev/2011-October/014398.html
> 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                   http://www.upfrontsystems.co.za
> _______________________________________________
> For more information about ZODB, see http://zodb.org/
>
> ZODB-Dev mailing list  -  ZODB-Dev@zope.org
> https://mail.zope.org/mailman/listinfo/zodb-dev
>
_______________________________________________
For more information about ZODB, see http://zodb.org/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev

Reply via email to