On Fri, 8 Mar 2013 20:33:44 +0200,
Roché Compaan ro...@upfrontsystems.co.za wrote :
A very simple alternative to prefetching would be to load the whole DB
into memory indiscriminately, if it is configured to do so. This way,
you can store your catalog in a separate db and request all of it from
Le Friday 08 March 2013 18:50:09, Laurence Rowe a écrit :
It would be great if there was a way to advise ZODB in advance that
certain objects would be required so it could fetch multiple object
states in a single request to the storage server.
+1
I can see this used to process a large tree,
On Sat, Mar 9, 2013 at 5:50 AM, Vincent Pelletier plr.vinc...@gmail.com wrote:
Le Friday 08 March 2013 18:50:09, Laurence Rowe a écrit :
It would be great if there was a way to advise ZODB in advance that
certain objects would be required so it could fetch multiple object
states in a single
On Sat, Mar 9, 2013 at 9:02 AM, Jim Fulton j...@zope.com wrote:
...
I think a simple method on a storage that gives a hint that a set of
object ids will be loaded is enough. A network storage could then
issue a pipelined request for those oids. The application can then
proceed as usual. I
I'd be curious to know what your results are, whichever path you decide to
take! Might help inform me as to what might help on my server...
One thing I haven't yet understood is - how come the ZEO server itself
doesn't have a cache? It seems that would be a logical place to put one as
the ZEO
On Fri, Mar 8, 2013 at 2:17 PM, Claudiu Saftoiu csaft...@gmail.com wrote:
Once I know the difference I'll probably be able to answer this myself,
but I wonder why the ZEO server doesn't do the sort of caching that allow
the client to operate so quickly on the indices once they are loaded.
On Fri, Mar 8, 2013 at 12:31 PM, Leonardo Santagada santag...@gmail.comwrote:
On Fri, Mar 8, 2013 at 2:17 PM, Claudiu Saftoiu csaft...@gmail.comwrote:
Once I know the difference I'll probably be able to answer this myself,
but I wonder why the ZEO server doesn't do the sort of caching that
It would be great if there was a way to advise ZODB in advance that
certain objects would be required so it could fetch multiple object
states in a single request to the storage server.
I saw a ZODB prefetching discussion long time ago, but maybe the
authors themselves can weight in here
A very simple alternative to prefetching would be to load the whole DB
into memory indiscriminately, if it is configured to do so. This way,
you can store your catalog in a separate db and request all of it from
the ZEO server and cache it straight away.
I'm still partial to a memcached cache
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
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.
This mail from Jim at this list a couple of years ago was stocked full
of nice tips:
https://mail.zope.org/pipermail/zodb-dev/2011-May/014180.html
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
Thanks, there are definitely some settings relating to the persistent
cache that I haven't tried before, simply because I've been avoiding
them.
I'd still be interested to know if one can leverage the Relstorage
memcache code for a ZEO cache, so if Shane doesn't get around to it
I'll have a stab
13 matches
Mail list logo
