I like that you enjoy optimizing things and golfing code down to fit in tweets.
Thanks ^_^
[comment about keys blocking]
I agree with the analysis and conclusions here.
The code Molly posted was adapted from this worker. I didn't know about Redis#scan_each, though. That completely obviates our manual tracking of the cursor, which I really like.
Aye, +1 for scan_each. Also, note that on the last iteration, when the cursor is "0", there can be keys that were returned with the cursor, which the worker won't expire, b/c it won't execute the loop body on that last response.
eg:
$ ruby -r redis -e'
redis = Redis.new
p count_from_keys: redis.eval(%(return #redis.call("keys", "rpush:notifications:*")), [0])
cursor = count = 0
until (cursor, keys = redis.scan(cursor, match: "rpush:notifications:*")).first.to_i.zero?
count += keys.size
end
p count_from_loop: count, final_key_size: keys.size
'{:count_from_keys=>1200000}{:count_from_loop=>1199998, :final_key_size=>2}
Thanks ^_^
I agree with the analysis and conclusions here.
Aye, +1 for
scan_each. Also, note that on the last iteration, when the cursor is"0", there can be keys that were returned with the cursor, which the worker won't expire, b/c it won't execute the loop body on that last response.eg:
Ooh, nice catch! I'll go ahead and port that worker over to use
scan_each. Thanks Josh!