jackrabbit-dev mailing list archives

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

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

Julian Reschke commented on JCR-1501:

>> But the point of the test was not to test the cache
>but that's what the test does in core from my point of view. you don't modify anything
while executing the test.
>therefore Session.refresh(false) doesn't have to revert any in the core.

In which case I think the test should be rewritten so that separate sessions are used.

>> So I don't think that enhancements wrt to JCR-1012 will really help
>why not? if jcr2spi can find out that nothing changed refreshing a tree doesn't do anything.
and if something changed the invalidation can be executed specifically
>instead of being applied to the complete tree.

It does help in cases where the information being requested was already requested by the session.
But that's not what the point of this benchmark was.

The only reason why it loops is to (a) take care of the potential optimzations the VM is doing,
and (b) to get reliable numbers.

> 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