2 ms·
The article concludes: "The return on implementation complexity of using jittered backoff is huge, and it should be considered a standard approach for remote cl
by cpeterso 5y ago
The article concludes: "The return on implementation complexity of using jittered backoff is huge, and it should be considered a standard approach for remote clients." But if I am reading the graphs correctly, the "None" backoff algorithm was twice as fast as the jitter algorithms but didn't get any mention in the text. What am I missing?
- gwittel 5y agoIts not presented in a very clear way from the charts alone -- Here the goal was to reduce/optimize the amount of unnecessary 'work' done. There is an implied cost of handling more work where contention is the root cause of extra (unnecessary) work. We're basically saying "I'd rather have a little more latency vs handle X times higher load". One common real world situation where this comes into play are things like thundering herd scenarios. Rather than trying to cope with huge bursts of traffic, we want to spread the load out in time.
- grkvlt 5y agowhat you are missing is that there are two sets of graphs, since there are two ways of measuring performance: number of calls (scales as n^2 with no backoff) and time to completion (scales linearly with no backoff) and an unjittered backoff will improve the number of calls while making the time to completion hugely worse (exponential?) - but jittered backoff looks to drop the number of calls substantially and also scales almost linearly, while still not doing too badly on time to completion.