[
https://issues.apache.org/jira/browse/OAK-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16467283#comment-16467283
]
Marcel Reutegger commented on OAK-6087:
---------------------------------------
I ran some more tests on a three node replica-set. The setup is basically what
Tomek built [here|https://github.com/trekawek/global-mongo]. The members in the
replica-set were also tagged. The primary and secondary in the first datacenter
with {{dc:dc1}} and the other (near) secondary with {{dc:dc2}}. The latency is
only between Oak and the first datacenter where the primary and a secondary are
located. The connection to the other secondary does not have additional latency.
All were performed with
{noformat}
w=majority&readPreference=secondaryPreferred&readPreferenceTags=dc:dc2&readPreferenceTags=
{noformat}
and each benchmark was run three times.
The ConcurrentReadWriteTest measures read operations while the system is under
load with 20 more readers and one writer. The client session doesn't show a
significant impact on the minimum and 10 percentile timings, but the 90
percentile is already noticeably better and maximum time drops significantly.
{noformat}
# latency 5ms
# ConcurrentReadWriteTest C min 10% 50% 90% max
N
# oak.mongo.clientSession = false
Oak-Mongo 1 102 191 269 425 2291
173
Oak-Mongo 1 137 201 280 563 2300
164
Oak-Mongo 1 119 188 278 435 1980
178
## oak.mongo.clientSession = true
Oak-Mongo 1 145 207 285 436 654
196
Oak-Mongo 1 126 183 261 369 1273
215
Oak-Mongo 1 106 196 268 391 1246
205
{noformat}
ConcurrentCreateNodesTest adds nodes with 20 concurrent writers. The test is
write heavy, but also performs many read operations, because the
DocumentNodeStore must check whether a node already exists when it is added.
Timings are slightly better with 5ms latency to the primary and the difference
becomes bigger with higher latency (e.g. 20 ms).
{noformat}
# latency 5ms
# ConcurrentCreateNodesTest
# oak.mongo.clientSession = false
Oak-Mongo 1 3670 3672 4136 4665 4756
15
Oak-Mongo 1 3735 3761 4039 4388 4617
15
Oak-Mongo 1 3740 3747 4079 4614 4957
15
# oak.mongo.clientSession = true
Oak-Mongo 1 3356 3411 3836 4335 4537
16
Oak-Mongo 1 3364 3396 3748 4006 4220
17
Oak-Mongo 1 3500 3550 3814 4373 4463
16
{noformat}
{noformat}
# latency 20ms
# ConcurrentCreateNodesTest
# oak.mongo.clientSession = false
Oak-Mongo 1 6940 6940 7242 7900 7900
9
Oak-Mongo 1 6960 6960 7401 7970 7970
9
Oak-Mongo 1 6972 6972 7173 7729 7729
9
# oak.mongo.clientSession = true
Oak-Mongo 1 5610 5617 5877 6159 6191
11
Oak-Mongo 1 5661 5679 5950 6296 6313
11
Oak-Mongo 1 5503 5538 6145 6649 6666
10
{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)
