OnParentVersion
All tests involved creating a single object node with one or more descendant nodes. Versioning had three modes: enabled on all test objects (TRUE), disabled on all test objects (FALSE), or enabled on the root object and on half of the children (HALF). onParentVersion was set to either VERSION or COPY (for non-versioned tests this has no effect). Scaling was tested by increasing the number of descendants (100, 1000) and by increasing the size of the jcr:content property on the descendant (roughly 10kb vs 1mb). Three types of descendant nodes were tested: auto-named children nodes with auto-generated intermediate folders (child), named children nodes (named), and datastreams (DS).
After all the descendants were created and assigned the versionable mixin where appropriate, a single new version of the root node was created.
Time to create a new version of the root node
The creation of a new version of the root node was only a small portion of the overall time spent in setting up each test (~1.6% mean, 7.6% max), although there was a significant increase in the amount of time required when auto-named children were used as the descendants.
Versioning Mode | Descendant Type | COPY | VERSION | Grand Total |
---|---|---|---|---|
HALF | child | 30.508 | 36.854 | 67.362 |
DS | 9.103 | 6.322 | 15.425 | |
named | 24.17 | 9.799 | 33.969 | |
TRUE | child | 135.928 | 191.543 | 327.471 |
DS | 39.017 | 15.31 | 54.327 | |
named | 64.466 | 12.217 | 76.683 |
Disk Usage
Results for disk usage were inconsistent, particularly for small batches where in some cases the size of the binary store actually decreased after a test, possibly due to background cleanup processes occurring in Modeshape. Binary content was never duplicated in any of the descendant types or onParentVersion modes tested. Tests with small binary content streams but large numbers of descendants demonstrated a much larger final disk usage to
Descendant Type | Number of descendants | Binary size | Not Versioned | COPY | VERSION |
---|---|---|---|---|---|
child | 100 | 10000 | 2880.571429 | 7259.2 | 7808 |
1000000 | 132636 | 136706.4 | 136629.6 | ||
1000 | 10000 | 37094.4 | 77579.2 | 77143.2 | |
1000000 | 1325440 | 1368764 | 1370260 | ||
DS | 100 | 10000 | 1678.352941 | 3506.8 | 2658.8 |
1000000 | 102832 | 105066.4 | 104563.2 | ||
1000 | 10000 | 16443.2 | 33852.8 | 31444.8 | |
1000000 | 1315988 | 1331370 | 1324400 | ||
named | 100 | 10000 | 3088 | 6360 | 4472 |
1000000 | 132012 | 135294.4 | 133525.6 | ||
1000 | 10000 | 33792 | 63904 | 47862.66667 | |
1000000 | 1323540 | 1353080 | 1336844 |
Full data results:
https://docs.google.com/spreadsheets/d/1SnFE-mUMEJnFUr3hXvg8UVBhnl4pq05lDTGlGR_VwYw
Multiple versions of the same object
Created a single object with one datastream
Performance drop-off was considerably faster when numerous datastreams (1000) were added to the root node prior to creating many new versions of the node.
Data
https://docs.google.com/spreadsheets/d/1QRieqQTq4LtR5r5AU0LpUPO7_C_ieBNGKU1ezqSrG5M