Roché Compaan wrote at 2008-2-1 21:17 +0200:
>I have completed my first round of benchmarks on the ZODB and welcome
>any criticism and advise. I summarised our earlier discussion and
>additional findings in this blog entry:
In your insertion test: when do you do commits?
One per insertion? Or one per n insertions (for which "n")?
Your profile looks very surprising:
I would expect that for a single insertion, typically
one persistent object (the bucket where the insertion takes place)
is changed. About every 15 inserts, 3 objects are changed (the bucket
is split) about every 15*125 inserts, 5 objects are changed
(split of bucket and its container).
But the mean value of objects changed in a transaction is 20
in your profile.
The changed objects typically have about 65 subobjects. This
fits with "OOBucket"s.
0.23 s would be 230 ms not 23 ms.
The reason for the dramatic drop from 10**6 to 10**7 cannot lie in the
BTree implementation itself. Lookup time is proportional to
the tree depth, which ideally would be O(log(n)). While BTrees
are not necessarily balanced (and therefore the depth may be larger
than logarithmic) it is not easy to obtain a severely unbalanced
tree by insertions only.
Other factors must have contributed to this drop: swapping, cache too small,
Furthermore, the lookup times for your smaller BTrees are far too
good -- fetching any object from disk takes in the order of several
ms (2 to 20, depending on your disk).
This means that the lookups for your smaller BTrees have
typically been served directly from the cache (no disk lookups).
With your large BTree disk lookups probably became necessary.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org