jackrabbit-dev mailing list archives

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

     [ https://issues.apache.org/jira/browse/JCR-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

angela resolved JCR-1501.

    Resolution: Incomplete

i run the benchmark with various configuration settings and the changes made with issue JCR-1815:

> CacheBehavior.OBSERVATION vs CacheBehavior.INVALIDATION
> Batch-Reading files/folders vs disabling BatchRead
> SPI implementation sending null vs Iterator upon NodeInfo.getChildInfos

- Refresh is expensive with CacheBehavior.INVALIDATION only
- simply accessing Item without refresh/login is slower with CacheBehavior.OBSERVATION

since i left the test that re-accessed the items without refresh/logout in order to get an
of the caching in jcr2spi, but didn't play around with cache-size. the latter would be useful,
since items get reloaded from the SPI if the itemstate/item is g-collected.

regarding the poor performance of getting big collections: i dare saying that the original
test didn't show that. in order to have better test data i'd suggest to add tests that create
a lot of big collections and access them randomly to address the concerns expressed by julian.

resolving incomplete.

> 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