4 ms·
Can't wait for Threaded I/O as our app main bottleneck in some deployments was Redis.
by xfalcox 7y ago
Can't wait for Threaded I/O as our app main bottleneck in some deployments was Redis.
- antirez 7y agoThreading can help up to a given point but sharing is the way to go.
- xfalcox 7y agoOne of our bottlenecks was really big keys (>1MB) being written and read too often and effectively stealing all the CPU time. That was fixed in the app by reducing the number of operations + compression. Threaded IO will give us a little more room. Other use case involves LUA scripts that operate on 5 different keys, so cluster/proxy is out of question.
- antirez 7y agoOh I saw a wonderful (private) fork about this, sending very large keys using threads.
- rakoo 7y agoGenuinely curious, why do you need such big keys ? Can't you hash them so you get nice short SHA-X strings for instance ?
- jdsully 7y agoI run a fork called KeyDB with multithreading as well as a few optimizations directly around large values (redis does unnecessary copies). It may work well for your use case. https://github.com/JohnSully/KeyDB https://github.com/JohnSully/KeyDB