[ 
https://issues.apache.org/jira/browse/OAK-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15585767#comment-15585767
 ] 

Chetan Mehrotra edited comment on OAK-1312 at 10/18/16 3:35 PM:
----------------------------------------------------------------

h4. Benchmark

Implemented a benchmark and committed that to trunk in r1765455. It
 has 3 parts
* main - The code here create an app:Asset structure 
* Reader - This thread does reads of random assets and read the 
'jcr:content/metadata/status' property
* Mutator - This thread modifies the status property of random asset nodes

h4. Benchmark - Overhead of new bundling logic when bundling *not* in use

It does not depend on bundling api and first purpose is to see overhead of new 
bundling logic when bundling feature itself is not used.

{noformat}
# BundlingNodeTest                 C     min     10%     50%     90%     max    
   N Reader  Mutator  Assets#
trunk
Oak-Mongo-DS                       1     189     280     432     817    1414    
 123   75403    2817    1390      #oak:Resource  (trunk)
Oak-Mongo-DS                       5     362     489     735    1612    2740    
 340   75093    2464    3580      #oak:Resource (trunk)
branch
Oak-Mongo-DS                       1     224     292     453     732    1591    
 122   77328    2794    1400      #oak:Resource (OAK-1312 branch)
Oak-Mongo-DS                       5     336     489     735    1476    2787    
 349   73245    2496    3660      #oak:Resource (OAK-1312 branch)
{noformat}

With above numbers it can be concluded that there is no overhead of bundling 
related change in critical path


was (Author: chetanm):
h4. Benchmark

Implemented a benchmark and committed that to trunk in r1765455. It
 has 3 parts
* main - The code here create an app:Asset structure 
* Reader - This thread does reads of random assets and read the 
'jcr:content/metadata/status' property
* Mutator - This thread modifies the status property of random asset nodes

h4. Benchmark - Overhead of new bundling logic when bundling not in use

It does not depend on bundling api and first purpose is to see overhead of new 
bundling logic when bundling feature itself is not used.

{noformat}
# BundlingNodeTest                 C     min     10%     50%     90%     max    
   N Reader  Mutator  Assets#
Oak-Mongo-DS                       1     189     280     432     817    1414    
 123   75403    2817    1390      #oak:Resource  (trunk)
Oak-Mongo-DS                       5     362     489     735    1612    2740    
 340   75093    2464    3580      #oak:Resource (trunk)

Oak-Mongo-DS                       1     224     292     453     732    1591    
 122   77328    2794    1400      #oak:Resource (OAK-1312 branch)
Oak-Mongo-DS                       5     336     489     735    1476    2787    
 349   73245    2496    3660      #oak:Resource (OAK-1312 branch)
{noformat}

With above numbers it can be concluded that there is no overhead of bundling 
related change in critical path

> Bundle nodes into a document
> ----------------------------
>
>                 Key: OAK-1312
>                 URL: https://issues.apache.org/jira/browse/OAK-1312
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core, documentmk
>            Reporter: Marcel Reutegger
>            Assignee: Chetan Mehrotra
>              Labels: performance
>             Fix For: 1.6
>
>         Attachments: OAK-1312-meta-prop-handling.patch, 
> OAK-1312-review-v1.diff, OAK-1312-review-v2.diff
>
>
> For very fine grained content with many nodes and only few properties per 
> node it would be more efficient to bundle multiple nodes into a single 
> MongoDB document. Mostly reading would benefit because there are less 
> roundtrips to the backend. At the same time storage footprint would be lower 
> because metadata overhead is per document.
> Feature branch - 
> https://github.com/chetanmeh/jackrabbit-oak/compare/trunk...chetanmeh:OAK-1312



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to