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:06:44 GMT

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

Julian Reschke 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. 

Sure. But the point of the test was not to test the cache, but the performance in browsing
collections. In general caching will not help in these cases, because the request will come
from different users (== sessions) and on different collections. So I don't think that enhancements
wrt to JCR-1012 will really help -- it would just mean that the test would need to be rewritten
to use separate sessions.





> 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.


Mime
View raw message