[
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 idea
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 nodes.
> - 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.
