Does name length affect performance in Redis?

I like to use verbal names in Redis, like set-allBooksBelongToUser:$userId .

Is this normal or does it affect performance?

+109
redis
Jun 12 2018-11-11T00:
source share
4 answers

The key you are talking about using is actually not so long.

The sample key that you specify for the set sets the O (1) search methods. More complex set operations (SDIFF, SUNION, SINTER) - O (N). Most likely, filling $userId was more expensive than using a longer key.

Redis comes with a test utility called redis-benchmark , if you change the GET test to src / redis-benchmark.c so that they are just "foo", you can run the test with short keys after make install :

 diff --git a/src/redis-benchmark.cb/src/redis-benchmark.c --- a/src/redis-benchmark.c +++ b/src/redis-benchmark.c @@ -475,11 +475,11 @@ benchmark("MSET (10 keys)",cmd,len); free(cmd); - len = redisFormatCommand(&cmd,"SET foo:rand:000000000000 %s",data); + len = redisFormatCommand(&cmd,"SET foo %s",data); benchmark("SET",cmd,len); free(cmd); - len = redisFormatCommand(&cmd,"GET foo:rand:000000000000"); + len = redisFormatCommand(&cmd,"GET foo"); benchmark("GET",cmd,len); free(cmd); 

Here's the GET test speed for the 3 subsequent runs of the foo shortcut:

 59880.24 requests per second 58139.53 requests per second 58479.53 requests per second 

Here's the speed of the GET test after changing the source again and changing the key to "set-allBooksBelongToUser: 1234567890":

 60240.96 requests per second 60606.06 requests per second 58479.53 requests per second 

Changing the key once again to the "ipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumlorem: 1234567890" gives the following:

 58479.53 requests per second 58139.53 requests per second 56179.77 requests per second 

Thus, even really very long keys do not have much effect on redis speed. And this is on GET, operation O (1). More complex operations will be even less sensitive to this.

I think that having keys that clearly define what values โ€‹โ€‹they have significantly outweighs any insignificant speed that you choose from shortened keys.

If you want to take this additionally, there is also the -r [keyspacelen] parameter in the redis-benchmark utility that allows you to create random keys (if they have ": rand:"), you can simply increase the size of the prefix in the test code to any desired length .

+169
Jun 12 '11 at 16:08
source share

Redis loves to keep all the keys in mind. The longer the average key length, the less can be stored in memory. So yes, key length can significantly affect performance, but probably not as much as you. That is, with a small key space (for example, with ease in memory), a 128-byte key and a 16-byte key will not be executed differently.

+23
Jun 16 2018-11-11T00:
source share

I cannot answer this question with any certainty. However, I can ask some questions and suggest some observations.

I think it is obvious that extremely long keys (names) and / or values โ€‹โ€‹will have a performance impact on overall performance, if they can be used at all. These effects can be on the client, over the network, or on the server. So, the first question to get out of you will be:

How long will keys and values โ€‹โ€‹last between Redis and your clients?

Redis searches, key lengths and restrictions limit me to an interesting Redis vs. blog post. memcached , which may begin to answer your question. The first response to this blog entry was apparently written by Salvatore Sanfilipo, the creator of Redis (early last fall: 09/2010), suggesting that the newer version will show significantly better results. Two comments on this occasion connected us with the Salvatore Redis / memcached Benchmark , which was published a few days after it responded to the original "blagger" (which seems anonymous).

This does not answer questions (how long keys can be and at what points performance hits are detected). However, this gives us the key to approaching the issue.

The authors of both of these articles wrote code and tested it ... and drew the results.

We could make all kinds of guesses. We could look at the code and try to justify it.

However, the most significant way to approach this issue is to write some code to measure one suggested usage pattern ... and a little more to test another (for example, a range of key lengths from 8 characters to ... how long would you like ... 8 kilobytes ?) ... and measure it.

+4
Jun 12 '11 at 10:32
source share

I donโ€™t think that the length of the variable name will affect performance, the variable will occupy the same place as any variable for this data type, unless you exceed the maximum length of the name.

-5
Jun 12 2018-11-11T00:
source share



All Articles