[
https://issues.apache.org/jira/browse/JCR-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12834250#action_12834250
]
Michael Dürig commented on JCR-2498:
------------------------------------
As promised some numbers. All measurements are done using
ReadPerformanceTest.java [1].
Batch size: 24340, 12170, 6085, 3043, 1521, 761, 380, 190, 95, 48, 24, 12, 6,
3, 1
ms per request: 20.2, 24.2, 17.4, 16.3, 7.3, 3.0, 2.5, 2.1, 2.0, 1.3, 1.3, 1.1,
1.0, 1.0, 1.1
The performance impact of large batches is clearly visible here. Without
refresh operations [2] the picture remains similar but less pronounced:
Batch size: 24340, 12170, 6085, 3043, 1521, 761, 380, 190, 95, 48, 24, 12, 6,
3, 1
ms per request: 5.1, 17.1, 16.3, 12.0, 6.0, 2.6, 2.7, 2.0, 2.0, 1.4, 1.4, 1.2,
1.0, 1.1, 1.3
[1]
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-jcr2spi/src/test/java/org/apache/jackrabbit/jcr2spi/benchmark/ReadPerformanceTest.java?revision=910523&view=markup&pathrev=910523
[2] See upcoming patch
> Implement caching mechanism for ItemInfo batches
> ------------------------------------------------
>
> Key: JCR-2498
> URL: https://issues.apache.org/jira/browse/JCR-2498
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr2spi, jackrabbit-spi
> Reporter: Michael Dürig
> Assignee: Michael Dürig
>
> Currently all ItemInfos returned by RepositoryService#getItemInfos are placed
> into the hierarchy right away. For big batch sizes this is prohibitively
> expensive. The overhead is so great (*), that it quickly outweighs the
> overhead of network round trips. Moreover, SPI implementations usually choose
> the batch in a way determined by the backing persistence store and not by the
> requirements of the consuming application on the JCR side. That is, many of
> the items in the batch might never be actually needed.
> I suggest to implement a cache for ItemInfo batches. Conceptually such a
> cache would live inside jcr2spi right above the SPI API. The actual
> implementation would be provided by SPI implementations. This approach allows
> for fine tuning cache/batch sizes to a given persistence store and network
> environment. This would also better separate different concerns: the purpose
> of the existing item cache is to optimize for the requirement of the consumer
> of the JCR API ('the application'). The new ItemInfo cache is to optimize for
> the specific network environment and backing persistence store.
> (*) Numbers follow
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
