[
https://issues.apache.org/jira/browse/OAK-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16467305#comment-16467305
]
Marcel Reutegger commented on OAK-6087:
---------------------------------------
For completeness, without latency, numbers look slightly better when client
sessions are disabled:
{noformat}
# latency 0ms
# ConcurrentCreateNodesTest
# oak.mongo.clientSession = false
Oak-Mongo 1 3146 3176 3505 4203 4509
17
Oak-Mongo 1 3160 3183 3443 4248 4641
18
Oak-Mongo 1 3164 3185 3558 4428 4587
17
# oak.mongo.clientSession = true
Oak-Mongo 1 3415 3577 3933 4663 4764
16
Oak-Mongo 1 3267 3324 3707 4732 5432
16
Oak-Mongo 1 3007 3129 3459 4530 4988
17
{noformat}
> Avoid reads from MongoDB primary
> --------------------------------
>
> Key: OAK-6087
> URL: https://issues.apache.org/jira/browse/OAK-6087
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk
> Reporter: Marcel Reutegger
> Assignee: Marcel Reutegger
> Priority: Major
> Labels: scalability
> Attachments: OAK-6087.patch
>
>
> With OAK-2106 Oak now attempts to read from a MongoDB secondary when it
> detects the requested data is available on the secondary.
> When multiple Oak cluster nodes are deployed on a MongoDB replica set, many
> reads are still directed to the primary. One of the reasons why this is seen
> in practice, are observers and JCR event listeners that are triggered rather
> soon after a change happens and therefore read recently modified documents.
> This makes it difficult for Oak to direct calls to a nearby secondary,
> because changes may not yet be available there.
> A rather simple solution for the observers may be to delay processing of
> changes until they are available on the near secondary.
> A more sophisticated solution discussed offline could hide the replica set
> entirely and always read from the nearest secondary. Writes would obviously
> still go to the primary, but only return when the write is available also on
> the nearest secondary. This guarantees that any subsequent read is able to
> see the preceding write.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
