[Chris Withers]
Having problems with a storage/client combo that have started having
really bad performance problems since moving to Zope 2.9.3.

The client becomes totally unresponsive, to the point where I had to
install DeadlockDebugger to get any sense out of it :-/

Anyway, with that in place, most often the threads seem to be in:

   File "/usr/local/zope/2.9.3/lib/python/ZEO/ServerStub.py", line 192,
in loadEx
     return self.rpc.call("loadEx", oid, version)

...when things are "slow".

What is LoadEx actually going?

Ignoring the `version` argument, loadEx(oid, version) is now the
normal way for a ZEO client to ask the ZEO server for the current
revision of the object with object id `oid`.  "Ex" is short for
"extended", and loadEx() is "an extended" form of load() introduced to
support MVCC.  MVCC support needs to know the tid that wrote the most
recent revision, and the pre-MVCC load() didn't supply that.  loadEx()
does return that tid (in addition to the object pickle, of course).

Recent changes in this setup were to move to Zope 2.7 to 2.9, although
no real problems were reported for the first day or two, so I'm not sure
of this.

At the same time, I moved to using temporary rather than persistent
client caches. Could this be to blame?

Sure, but no way to guess from here.  The only thing I can really
guess from the above is that your client is going to the server a lot
to get data.  Of course it shouldn't do that if it finds the current
revision in the ZEO client cache.  If the sloth is acute for a period
following  client startup, but gets better over time, then the lack of
a persistent client cache would be the obvious suspect.
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

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

Reply via email to