我正在尝试对我的redis SUNION命令进行基准测试。虽然基准测试其中一个集合包含~1000个元素，而其他集合包含~10个元素。
每次调用的执行顺序约为0.52 ms。
这个性能是理想的还是我错过了conf文件中的某些调整设置。
我正在尝试使用基本集操作在对象上实现标记过滤。对于前者obj1 -> {id - 1 colour red location x}
obj1 -> {id - 1 colour red location x} obj2 -> { id - 2 colour yellow location y} obj3 -> { id - 3 clolour red location y}
为了存储我正在使用集合来存储每个维度的对象ID。因此
colour:red -> {1,3} colour:yellow -> {2} location:x -> {1} location:y -> {2,3}
这使我能够在这个上面暴露apis：在位置x红色的对象x在任何位置红色的对象
这些中的每一个实际上都转化为多个集合操作，使用我使用管道实现的联合交集差异。
比例：任何一组内的最大元素数量都非常少~5000。延迟是考虑的重点。如果我有任何其他方式来实现这种表现。会有所帮助。
我不知道性能是否理想（听起来不错，在我的书中不到1毫秒很棒，但这实际上取决于你的要求）。
我在笔记本电脑上进行了以下测试：
$ for i in `seq 0 999`; do redis-cli sadd s1000 forbar$i; done
...
$ for i in `seq 0 9`; do redis-cli sadd s10 foobar$i; done
...
$ redis-benchmark SUNION s1000 s10
...
100.00% <= 56 milliseconds
1171.37 requests per second
$ redis-benchmark SUNION s1000
...
100.00% <= 57 milliseconds
1062.70 requests per second
$ redis-benchmark SMEMBERS s1000
100.00% <= 19 milliseconds
3300.33 requests per second
$ redis-benchmark SINTER s1000
100.00% <= 17 milliseconds
3311.26 requests per second
...
127.0.0.1:6379> INFO
# Server
redis_version:999.999.999
redis_git_sha1:4e5e0d37
redis_git_dirty:1
redis_build_id:abfc1e37fd7acbf7
redis_mode:standalone
os:Darwin 17.7.0 x86_64
arch_bits:64
multiplexing_api:kqueue
atomicvar_api:atomic-builtin
gcc_version:4.2.1
process_id:23596
run_id:73b0f2f6795eccb8286fc086c83d89da45314ce2
tcp_port:6379
uptime_in_seconds:55429
uptime_in_days:0
hz:10
configured_hz:10
lru_clock:9775394
...
Hardware Overview:
Model Name: MacBook Pro
Model Identifier: MacBookPro11,4
Processor Name: Intel Core i7
Processor Speed: 2.2 GHz
Number of Processors: 1
Total Number of Cores: 4
L2 Cache (per Core): 256 KB
L3 Cache: 6 MB
Memory: 16 GB
Boot ROM Version: MBP114.0184.B00
SMC Version (system): 2.29f24
这些结果（以及一些挖掘代码）表明：