Exponential Backoff and Jitter

&gt; It’s worth noting that none of these approaches fundamentally change the N^2 nature of the work to be done, but do substantially reduce work at reasonable levels of contention.<p>I don&#x27;t think that statement from the article is true if I understood correctly... the performance gains are precisely because you&#x27;re reducing from N^2 to N log N.<p>An interesting theoretical question would be to identify the optimal backoff policy. I think FullJitter should be close to optimal, but maybe you can squeeze out a little more with something more sophisticated.<p>Edit: I just realized the DecorrelatedJitter (not sure why it&#x27;s called that?) makes a lot of sense as a minor optimization because if you already waited a long time and still failed, that suggests there is a lot of contention, and you should wait even longer.

Great post. There&#x27;s a classic LBL paper about self-synchronization in (I think) time protocols that demonstrates the same conclusion in a more dramatic way.

What a coincidence, I found myself writing a little Go lib for exponential back off yesterday, and was wondering what the purpose of introducing jitter was and what effects it would have. I need it for interacting with the Twitter stream api and they&#x27;re pretty clear that when they say exponential they mean it. But jitter looks very useful in some situations after reading this, so I added that to my lib as well...<p>It&#x27;s here if anyone&#x27;s interested it <a href="https://github.com/Diggs/go-backoff" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Diggs&#x2F;go-backoff</a>

Wouldn&#x27;t this be completely alleviated by placing each new connection into a queue, instead of rejecting it and telling the client to try again? Or am I reading this wrong?

The version with jitter but without exponential backoff is still doing O(n^2) work, I&#x27;m pretty sure, although with a (much) smaller constant.<p>Just something to keep in mind.<p>Also, I find the inherent time taken &#x2F; work done tradeoff interesting. Something involving a limited amount of server state might work better on the work front while keeping the work done limited. (Something like &quot;please don&#x27;t try again for x ms&quot; sent as a reply)<p>The ideal case is, what, 2n-1 calls (everyone sends at once, server replies to the first guy and schedules all other clients such that there is no contention) and O(n) (what is the scale factor here? 20ms?) delay? Are there any algorithms that come close to the limit?

I wish the experimenter had explored random distributions other than uniform. I suspect uniform distribution may be non-ideal here and other distributions may produce better results.

I&#x27;ve always thought of &quot;jitter&quot; as just adding a dash of entropy to the system I&#x27;m building.<p>I suppose a textbook example is... If I&#x27;m managing a pool of long-running threads I want to periodically bounce, I could write logic to throttle respawning threads. Or I could just add a rand() to the conditional -- introduce &quot;jitter&quot; -- and let probability theory &quot;throttle&quot; for me.<p>I&#x27;d rather build on top of probability than statistics.

Randomness is an easy way to ensure you&#x27;re not doing something systematically wrong.

Nice post.<p>Use of pure color in a graph makes me sad, though. This colorblind guy had to crack open a paint program and match up RGB values. A few dotted&#x2F;dashed lines go a long way (and I suspect, for more than just colorblind folks, too).