Hi, 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 needed): http://pastebin.com/pzwA74EN 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: self._inv_lock.acquire() 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 ? cheers, - steve [...snip...] -- 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 https://mail.zope.org/mailman/listinfo/zodb-dev
