MGET performs significantly worse than SORT (nosort) . . why?

[Kyle Bishop]

Created 100 keys from 0 to 99 and added them to a set in Redis 2.6 RC5

The results were not what I'd expected . . 

cumulus:src kbishop$ ./redis-benchmark -n 1000000 -q 'SORT set by nosort get * get #'

SORT set by nosort get * get #: 34760.85 requests per second

cumulus:src kbishop$ ./redis-benchmark -n 1000000 -q 'MGET 0 1 2 3 [...] 99'

MGET 0 1 2 3 [...] 99: 28380.07 requests per second

What the heck is going on here? How could providing a set of keys vs using a pre-existing set of keys incur such a performance hit? Is there some threshold of key length after which the redis commands are split into multiple packets or something? I would've expected MGET to perform better than SORT, not worse . . 

[Josiah Carlson]

My gut says parsing.

Redis needs to parse the arguments to the command, but in a
SORT/nosort situation, Redis doesn't really need to parse much of
anything. It only needs to fetch keys.

- Josiah

> --
> You received this message because you are subscribed to the Google Groups
> "Redis DB" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/redis-db/-/iWiD4VM0_AEJ.
> To post to this group, send email to redi...@googlegroups.com.
> To unsubscribe from this group, send email to
> redis-db+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/redis-db?hl=en.

[Alex Leverington]

Parsing and TCP. This is why list range requests are faster than hashes for such circumstances (sequential keys).

If you're running over TCP it's also caused when the MGET results in a packet larger than MTU, buffers, or TCP window size, such as an MGET with 20k keys; this results in added round-trips.

Using jumbo packets or a unix socket would make it less of an issue. Bit or sequential based *MGET* commands would be really cool though. Could be done with sprintf string as an input.

HMGETF myhash "field%i" 0 100 1

Would rock. It's been recommended to grab 2.6 and do this in Lua; avoids the network and parsing overhead.

--

Alex Leverington

214-282-5614

--