[
https://issues.apache.org/jira/browse/OAK-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated OAK-1417:
-------------------------------
Attachment: 0001-OAK-1417-Processing-pending-observation-events-does-.patch
The {{O\(n log n)}} assumption indeed seems to be the case here. The
{{Event.getPath()}} call in the test case is proportional to path length, which
in the test setup grows as a logarithm of the total number of nodes. With {{n}}
{{getPath()}} calls, the combined time becomes {{O\(n log n)}}.
The attached patch shortcuts the path mapping to a no-op for this test scenario
where there are no local namespace remappings. This brings the observed
performance scaling closer to {{O\(n)}} for the SegmentMK.
> Processing pending observation events does not scale linearly with the number
> of events
> ---------------------------------------------------------------------------------------
>
> Key: OAK-1417
> URL: https://issues.apache.org/jira/browse/OAK-1417
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk, segmentmk
> Reporter: Michael Dürig
> Attachments:
> 0001-OAK-1417-Processing-pending-observation-events-does-.patch
>
>
> {{org.apache.jackrabbit.oak.jcr.LargeOperationIT#largeNumberOfPendingEvents}}
> does not scale linearly. Neither on a segment nor on a document node store.
> This test asserts that the number of pending observation events (e.g. due to
> a large commit or cluster sync) has a linear processing time. That is the
> time it takes to process one such event is independent of the total number of
> events.
> {code}
> seg quotients: 0.24215928530697586, 0.4065934065934066, 1.7548262548262548,
> 0.6892189218921893, 1.2083000798084598
> doc quotients: 0.2990824434780629, 0.14113885505481122, 0.587378640776699,
> 1.3122130394857667, 142.65850244926523
> {code}
> While in the case of the segment node store the numbers do not seem too
> worrisome, the document node store seems to start lagging behind badly as
> soon as there are more than 32768 pending events.
> See OAK-1413 for how to read those numbers.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
