Improve ConsumerStateTable: del after consumed, and let consumer writes the final table#204
Conversation
|
whats the motivation behind this pr? #Resolved |
|
@kcudnik I modified the first comment to answer your question. #Closed |
| for f, v in pairs(fieldvalues) do | ||
| redis.call('HSET', tablename..key, f, v) | ||
| end | ||
| redis.call('DEL', stateprefix..tablename..key) |
There was a problem hiding this comment.
With the extra HSET and DEL processing, it looks the number of redis operations has been doubled. Is the performance impact a concern here?
Is it possible to compress all the data in sadd argument and process them after SPOP? #Resolved
There was a problem hiding this comment.
Since the requirement changes, performance is not the first concern here. I am open to any optimization suggestion.
Regarding compress, the SADD is used to keep keys, so we have chance to merge the operations on the same key. Compressing key/filed/value into SADD doesn't help.
In reply to: 191872386 [](ancestors = 191872386)
It looks vs test_FDBAddedAfterMemberCreated will fail with this change? |
jipanyang
left a comment
There was a problem hiding this comment.
Though it passed swss common unit test, the data left in DB table is wrong: Sequence number is taken as field while both the original field/value are set as value.
root@80fe1d6fbd69:/sonic/src/sonic-sairedis/tests# redis-cli -n 0
127.0.0.1:6379> hget UT_REDIS_THREAD_0:key 818 1
(error) ERR wrong number of arguments for 'hget' command
127.0.0.1:6379> hget "UT_REDIS_THREAD_0:key 818" 1
"field 0"
127.0.0.1:6379> hget "UT_REDIS_THREAD_0:key 818" 2
""
127.0.0.1:6379> hget "UT_REDIS_THREAD_0:key 818" 3
"field 1"
127.0.0.1:6379> hget "UT_REDIS_THREAD_0:key 818" 4
"value 1"
127.0.0.1:6379> hgetall "UT_REDIS_THREAD_0:key 818"
- "1"
- "field 0"
- "2"
- ""
- "3"
- "field 1"
- "4"
- "value 1"
- "5"
- "field 2"
- "6"
- "value 2"
- "7"
- "field 3"
- "8"
- "value 3"
- "9"
- "field 4"
- "10"
- "value 4"
- "11"
- "field 5"
- "12"
- "value 5"
- "13"
- "field 6"
- "14"
- "value 6"
- "15"
- "field 7"
- "16"
- "value 7"
- "17"
- "field 8"
- "18"
- "value 8"
- "19"
- "field 9"
- "20"
- "value 9"
- "21"
- "field 10"
- "22"
- "value 10"
- "23"
- "field 11"
- "24"
- "value 11"
- "25"
- "field 12"
- "26"
- "value 12"
- "27"
- "field 13"
- "28"
- "value 13"
- "29"
- "field 14"
- "30"
- "value 14"
- "31"
- "field 15"
- "32"
- "value 15"
- "33"
- "field 16"
- "34"
- "value 16"
- "35"
- "field 17"
- "36"
- "value 17"
- "37"
- "field 18"
- "38"
- "value 18"
- "39"
- "field 19"
- "40"
- "value 19"
- "41"
- "field 20"
- "42"
- "value 20"
- "43"
- "field 21"
- "44"
- "value 21"
- "45"
- "field 22"
- "46"
- "value 22"
- "47"
- "field 23"
- "48"
- "value 23"
- "49"
- "field 24"
- "50"
- "value 24"
- "51"
- "field 25"
- "52"
- "value 25"
- "53"
- "field 26"
- "54"
- "value 26"
- "55"
- "field 27"
- "56"
- "value 27"
127.0.0.1:6379>
Signed-off-by: Qi Luo <[email protected]>
Signed-off-by: Qi Luo <[email protected]>
Signed-off-by: Qi Luo <[email protected]>
Signed-off-by: Qi Luo <[email protected]>
552152d to
b073815
Compare
Signed-off-by: Qi Luo <[email protected]>
|
Correct data written to DB table after the fieldvalue set fix. thanks! |
Original implementation will have 2 issues: