Old Release

This documentation covers an old version of Fedora. Looking for another version? See all documentation.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

OnParentVersion with many descendants

 

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, when appropriate, a single new version of the root node was created (New Version Time).  Total time spent creating descendants and enabling versioning on them is recorded as Total Child Creation Time.

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.  Generally, using COPY mode resulted in a slower new version creation times than VERSION.

 

Descendant Type# of DescendantsBinary sizeCOPYVERSION
child
100
10000572616.0666667
  10000001119.8956
 
1000
100007227.47463
  10000007600.57009
DS
100
10000172.275.7
  1000000222117
 
1000
100001369.2262.8
  10000001925.5288
named
100
10000432.654.5
  1000000438.499.8
 
1000
100005471.5247.8333333
  10000004986.5290

 

Disk Usage

Results for disk usage were not always consistent, 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.  Usage was measured by using the du command on the data directory before and after running the test.  Binary content was never duplicated in any of the descendant types or onParentVersion modes tested.  For descendants with larger binary content the increase in disk usage for using any type of versioning over not versioning was small.

 

Descendant TypeNumber of descendantsBinary sizeNot VersionedCOPYVERSION
child
100
100002880.57259.27808
  1000000132636136706.4136629.6
 
1000
1000037094.477579.277143.2
  1000000132544013687641370260
DS
100
100001678.33506.82658.8
  1000000102832105066.4104563.2
 
1000
1000016443.233852.831444.8
  1000000131598813313701324400
named
100
10000308863604472
  1000000132012135294.4133525.6
 
1000
10000337926390447862.6
  1000000132354013530801336844

Full data results:

https://docs.google.com/spreadsheets/d/1SnFE-mUMEJnFUr3hXvg8UVBhnl4pq05lDTGlGR_VwYw

 

Multiple versions of the same object

Created a single node with one datastream and then created new versions of the node:

 

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

https://docs.google.com/spreadsheets/d/10B0ZaIrNeb0GYqQsEZszVZinXAVD1qB7xz30xuI_yws

  • No labels