Does name length impact performance in Redis?

The key you're talking about using isn't really all that long.

The example key you give is for a set, set lookup methods are O(1). The more complex operations on a set (SDIFF, SUNION, SINTER) are O(N). Chances are that populating $userId was a more expensive operation than using a longer key.

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

diff --git a/src/redis-benchmark.c b/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 3 subsequent runs of the short key "foo":

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

Here's the GET test speed after modifying 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 yet again to "ipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumlorem:1234567890" gives this:

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

So even really really long keys don't have a large impact on the speed of redis. And this is on GET, a O(1) operation. More complex operations would be even less sensitive to this.

I think that having keys that clearly identify what values they hold greatly outweighs any minuscule speed performance you'd get out of abbreviated keys.

If you wanted to take this further, there's also a -r [keyspacelen] parameter on the redis-benchmark utility that lets it create random keys (as long as they have ':rand:' in them), you could just increase the size of the prefix in the testing code to whatever length you wanted.

Redis likes to hold all keys in memory. The longer your average key length, the less can be held in memory. So yes, key length can greatly impact performance but probably not significantly in the way you are concerned. That is, with a small keyspace (e.g. one that fits easily in memory), a 128 byte key and a 16 byte key won't perform dramatically differently.

I can't answer this question with any certainty. However, I can ask some questions about it and offer some observations.

I think it's obvious that extremely long keys (names) and/or values would have a performance impact on overall performance if they can be used at all. These impacts could be in the client, over the network, or on the server. So the first question to drag out of yours would be:

How long can the keys and values be between Redis and your clients?

Searching on Redis, key length and limits nets me an interesting blog entry on Redis vs. memcached which may start to answer your question. The first response to that blog entry appears to have been written by Salvatore Sanfilipo, creator of Redis (early last fall: 09/2010) suggesting that a more recent version would show significantly better results. Two comments down from that link us to Salvatore's Redis/memcached Benchmark which was posted a few days after he'd responded to the original "blagger" (who seems to be anonymous).

This doesn't answer the questions (how long can the keys be and at what points are there detectable impacts on performance). However, it gives us a clue about approach the question.

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

We could make all sorts of guesses. We could look at the code and try to reason it out.

However, the most meaningful way to approach a question of this sort is to write some code to measure one proposed usage pattern ... and some more to test another (for instance a range of key lengths ranging from 8 characters to ... how long would you like ... 8 kilobytes?) ... and the measure it.