[JAVA-459] smooth the latency measurements Created: 26/Oct/11  Updated: 19/Oct/16  Resolved: 28/Oct/11

Status: Closed
Project: Java Driver
Component/s: None
Affects Version/s: None
Fix Version/s: 2.7

Type: Improvement Priority: Major - P3
Reporter: Antoine Girbal Assignee: Antoine Girbal
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This is to avoid ignoring local servers because some measurements were bad.
Since we dont do just a ping but call isMaster, extra delay may appear.
The default smoothing factor is 4.0 and can be modified with com.mongodb.latencySmoothFactor



 Comments   
Comment by Antoine Girbal [ 27/Oct/11 ]

smoothing latency like this is what is implemented in many systems.
The common case is following:

  • by default driver will disregard slaves that are more than 15ms away from closest.
  • with no smoothing, any time a ping time is higher than 15ms slave will be disregarded for that period (5s). When it is due to load, it can lead to load imbalance and can start moving traffic back and forth between servers. This can lead to lower throughput and system instability.
  • with smoothing the latency would have to jump to at least 60s to disable that slave, so basically the selection is more stable. But at you mentioned the trade off is when a very bad latency happens, it takes more time to come back.
Comment by Remon van Vliet [ 27/Oct/11 ]

Can you comment on why local server measurements would be bad? It would seem that this solution could cause rather odd behaviour when big spikers occur, e.g. :

PING 1 : 0ms (smoothed 0)
PING 2 : 1ms (smoothed 1)
PING 3 : 0ms (smoothed 0)
PING 4 : 6113ms (smoothed 1527)
PING 5 : 1ms (smoothed 1144)
PING 6 : 1ms (smoothed 857)

In other words, a spike might disqualify the member as a suitable secondary for quite a long time and spikes will happen on distributed environments. Perhaps I misunderstood the solution.

Also, I sugest using System.nanoTime() for measurements like these since apart from being way more accurate for <1ms measurements it also avoid OS specific timer granularity. On a lot of OS granularity of System.currentTimeMillis() is significantly larger than 1ms.

Comment by auto [ 26/Oct/11 ]

Author:

{u'login': u'agirbal', u'name': u'agirbal', u'email': u'antoine@10gen.com'}

Message: JAVA-459: smooth the latency measurements
Branch: master
https://github.com/mongodb/mongo-java-driver/commit/d8aaf49ffa82c93cab1ce9c3e9985a80aa77db31

Generated at Thu Feb 08 08:52:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.