Redis Sets Performance Issue - performance

Question

I am trying to benchmark my redis SUNION command.
While benchmarking one of the sets contains ~ 1000 elements and other contains ~10 elements.
The order of execution is around 0.52 ms per call.
Is this performance ideal or am I missing out on some tuning settings in the conf file.
I am trying to implement tag filtering on objects using basic sets operations.
For ex.
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}
in order to store i am using sets for storing object ids for each dimensions.hence
colour:red -> {1,3}
colour:yellow -> {2}
location:x -> {1}
location:y -> {2,3}
This enables me to expose apis on top of this like :
objects coloured red in location x
objects coloured red in any location
each of these actually translates into multiple sets operations for me using union intersection diff which i have implemented using pipelines.
Scale :
The max number of elements inside any set is very less ~ 5000. And latency is the main point consider. If there is any other way that i should take to achieve this kind of performance. Would be helpful.

Answer 1

I don't know if the performance is ideal (sounds great, less than 1ms is great in my book, but it really depends on your requirements).
I've performed the below test on my laptop:
$ 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
These results (and some digging into the code) show that:
SUNION is slower than just getting the members of a set (SMEMBERS uses the same implementation as SINTER).
Iterating and replying with 1000 elements takes at least 17-19ms
The difference between SUNION and the others is not in orders of magnitude, which is good, but perhaps requires some optimizations in the Redis code (at least for this edge case).