We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
环境: 1、大约3千万条数据,几乎不存在局部热点数据; 2、cache_size和write_buffer_size配置最小值,目的就是减少内存,尽可能访问SSDB(硬盘是SSD的) 3、都是访问本地SSDB 问题: 一次请求大约会有200次访问SSDB,最开始方案是这200次请求是串行访问SSDB,发现耗时会出现几百毫秒的情况;后来使用multi_get(每次key的个数试过10,30,50,70等),发现耗时依然会有几百毫秒的情况。后来发现multi_get的源码如截图,是串行访问SSDB的,这样的话使用multi_get优化肯定是有限的。请问multi_get会考虑并行化吗?像我这种场景有合适的解决方案吗?(期望这200次请求访问SSDB的耗时在20ms左右) @ideawu 麻烦解答一下,非常感谢。
The text was updated successfully, but these errors were encountered:
SSDB 内部执行一个命令(包含带多个参数的 multi_xxx 类命令), 只使用一个线程. 执行多个命令可能使用多个线程. 所以, 需要在客户端自己并发地请求, 每一个并发只请求一个 key. 一般可以并发 100 个连接(每个连接使用一个线程, 或者编程语言支持协程). 或者并发 10 个连接, 每一次请求 10 个 key.
Sorry, something went wrong.
好的,多谢
No branches or pull requests
环境:

1、大约3千万条数据,几乎不存在局部热点数据;
2、cache_size和write_buffer_size配置最小值,目的就是减少内存,尽可能访问SSDB(硬盘是SSD的)
3、都是访问本地SSDB
问题:
一次请求大约会有200次访问SSDB,最开始方案是这200次请求是串行访问SSDB,发现耗时会出现几百毫秒的情况;后来使用multi_get(每次key的个数试过10,30,50,70等),发现耗时依然会有几百毫秒的情况。后来发现multi_get的源码如截图,是串行访问SSDB的,这样的话使用multi_get优化肯定是有限的。请问multi_get会考虑并行化吗?像我这种场景有合适的解决方案吗?(期望这200次请求访问SSDB的耗时在20ms左右)
@ideawu 麻烦解答一下,非常感谢。
The text was updated successfully, but these errors were encountered: