Last week I started this thread to try and figure out the bottle neck in our
web-app. After trying out different approaches, we decided to profile the app.
using repoze.profile[1] in the middleware and hit the app. using funkload[2].

This is what we saw for a test run: (although my question below is not related
to the specifics of the test run, details of the same can be provided if 


As you can see, most of the time is being spent, acquiring locks, or (validating
?) cache code.

After looking at ZODB3-3.10.2-py2.6-linux-x86_64.egg/ZODB/Connection.py line 864
(_setstate) (line 13 in that ^ paste), I think most of those acquire()s are
coming from line 900:


So, my question here is:
a. Is the invalidation-queue-size just a start-up time optimization or does it
play a part in invalidation of the zeo client cache for every transaction ? (we
use the repoze.zodbconn middleware, using which, every request to the webserver
is treated as a transaction)

b. Does drop_cache_rather_verify() play a part on a 'connected' zeo client --
ie: would the client always drop cache rather than verify each transaction or is
this just a startup optimization ?

- steve


random spiel: http://lonetwin.net/
what i'm stumbling into: http://lonetwin.stumbleupon.com/
For more information about ZODB, see http://zodb.org/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to