3 ms·
The blog post announcing this might be a better read: https://medium.com/@NetflixTechBlog/performance-under-load-3e6fa9a60581 https://medium.com/@NetflixTechBl
by jsnell 9y ago
The blog post announcing this might be a better read:
https://medium.com/@NetflixTechBlog/performance-under-load-3e6fa9a60581 https://medium.com/@NetflixTechBlog/performance-under-load-3...
(And while reading that and thinking "I swear I recently read something else talking about applying TCP congestion control to RPC queueing". And indeed I had: http://www.evanjones.ca/prevent-server-overload.html http://www.evanjones.ca/prevent-server-overload.html)
- cperciva 9y agoI swear I recently read something else talking about applying TCP congestion control to RPC queueing I did this almost 10 years ago for accessing Amazon SimpleDB, too: http://www.daemonology.net/blog/2008-06-29-high-performance-simpledb.html http://www.daemonology.net/blog/2008-06-29-high-performance-...
- Twirrim 9y agoHad a co-worker implement something similar to this dynamic throttling in a back-end analytical process, based around access of a DynamoDB table that was accessed by multiple front end services. The code on the back-end processing software would throttle itself back hard (about 50% of the speed it had reached) whenever it ran into a DynamoDB throttle message as a response, and then would ramp itself back up steadily. Combined with good retry logic on the front end services, it meant we could keep the DynamoDB table humming along at near maximum usage.