[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. |
| Comments |
| Comment by Antoine Girbal [ 27/Oct/11 ] |
|
smoothing latency like this is what is implemented in many systems.
|
| 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) 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: |