jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1501) poor performance on big collections
Date Fri, 03 Oct 2008 12:54:44 GMT

    [ https://issues.apache.org/jira/browse/JCR-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636621#action_12636621

angela commented on JCR-1501:

i took a closer look at the test cases and came to the conclusion that the performance is
lost due to the
Session.refresh(false) after each iteration, which in jcr2spi invalidates the complete tree
and rereads it
from the SPI upon next access.

Optimization of the refresh behavior is already covered by JCR-1012.

I suggest to separate the benchmark for 'accessing collections' from 'refresh the complete
my findings after modifying the tests:

        testGetChildren: 0.999000999000999ms per call (1001 iterations)
	testBrowseMinusJcrData: 5.46448087431694ms per call (183 iterations)
	testBrowse: 8.695652173913043ms per call (115 iterations)
	testRefreshFalse: 0.057723389517432465ms per call (17324 iterations)
	testRefreshTrue: 0.05501760563380282ms per call (18176 iterations)

spi2jcr	testGetChildren: 0.278473962684489ms per call (3591 iterations)
	testBrowseMinusJcrData: 1.8050541516245486ms per call (554 iterations)
	testBrowse: 3.5587188612099645ms per call (281 iterations)
	testRefreshFalse: 378.0ms per call (5 iterations)
	testRefreshTrue: 1678.0ms per call (5 iterations)

> poor performance on big collections
> -----------------------------------
>                 Key: JCR-1501
>                 URL: https://issues.apache.org/jira/browse/JCR-1501
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jackrabbit-jcr2spi
>            Reporter: Julian Reschke
> With JCR-1437, I have added tests for measuring performance, both using "plain" Jackrabbit
and through JCR2SPI.
> There are three tests (inside BigCollectionTest), all creating a collection of 500 nt:file
> - testGetChildren just instantiates the nodes
> - testBrowseMinusJcrData simulates browsing (getting metadata), but does not read jcr:data
> - testBrowse   simulates browsing (getting metadata), including obtaining the content
length (jcr:data)
> The tests can be run using
>   mvn -Dtest=JCRBenchmark test
> under both jackrabbit-core and jackrabbit-jcr2spi.
> The results that I see are:
> For plain Jackrabbit:
> testGetChildren: 0.20 ms per iteration
> testBrowseMinusJcrData: 1.15 ms per iteration
> testBrowse: 2.55 ms per iteration
> With JCR2SPI, I see:
> testGetChildren: 281 ms per iteration
> testBrowseMinusJcrData:  577 ms per iteration
> testBrowse: 643 ms per iteration
> So, at least for these tests, JCR2SPI is several orders of magnitude slower.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message