On Sun, 2008-02-03 at 22:05 +0100, Dieter Maurer wrote:
> The number of "persitent_id" calls suggests that a written
> persistent object has a mean value of 65 subobjects -- which
> fits well will OOBuckets.
> However, when the profile is for commits with 100 insertions each,
> then the number of written persistent objects is far too small.
> In fact, we would expect about 200 persistent object writes per transaction:
> the 100 new persistent objects assigned plus about as many buckets
> changed by these insertions.
I don't follow? There are 20000 insertions and there are 1338046 calls
to persistent_id. Doesn't this suggest that there are 66 objects
persisted per insertion? This seems way to high?
> > ....
> >The keys that I lookup are completely random so it is probably the case
> >that the lookup causes disk lookups all the time. If this is the case,
> >is 230ms not still to slow?
> Unreasonably slow in fact.
> A tree with size 10**7 does likely not have a depth larger than 4
> (internal nodes should typically have at least 125 entries, leaves should have
> at least 15 -- a tree of depth 4 thus can have about 125**3*15 = 29.x *
> Therefore, one would expect at most 4 disk accesses.
> On my (6 year old) computer, a disk access can take up to 30 ms.
The lookup times I reported were wrong. There was a bug in the code that
reported the lookup time - the correct average lookup time for a BTree
with 10 million objects was an impressive 12 ms. For Postgres this was
Upfront Systems http://www.upfrontsystems.co.za
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org