Stackexchange.redis: Server.Keys() call hangs

[deepaknc]

I have this code snippet on LinqPad

   Lazy<ConnectionMultiplexer> lazyConnection = new Lazy<ConnectionMultiplexer>(() =>
        {
            return ConnectionMultiplexer.Connect("<mycache>.redis.cache.windows.net,abortConnect=false,ssl=true,password=<mypassword>");
        });

   var connection = lazyConnection.Value;
   var server = connection.GetServer(connection.GetEndPoints()[0]);
   Console.Write(server.Keys(connection.GetDatabase().Database, "prefix*"));

This just hangs in the Keys call, and never returns back. The cache is quite responsive, and I'm able to make similar request from the redis-py python client library, which leads me to believe that it's the StackExchange client library which is the culprit.

[mgravell]

What server version is this, and how many keys to you have? On down-level
servers where only KEYS is available, yes: this can hurt. If SCAN is
available, the server can use that to reduce blocking (multiple small
requests). Note that if the administration commands are disabled, the
client won't know the server version - in which case you should explicitly
tell the library the server version in the configuration parameters - it
defaults to a safe lower-level default, where SCAN won't be assumed to be
available.
On 13 Aug 2015 8:48 am, "kobybecker" [email protected] wrote:

I have this code snippet on LinqPad

Lazy lazyConnection = new Lazy(() =>
{
return ConnectionMultiplexer.Connect(".redis.cache.windows.net,abortConnect=false,ssl=true,password=");
});

var connection = lazyConnection.Value;
var server = connection.GetServer(connection.GetEndPoints()[0]);
Console.Write(server.Keys(connection.GetDatabase().Database, "prefix*"));

This just hangs in the Keys call, and never returns back. The cache is
quite responsive, and I'm able to make similar request from the redis-py
python client library, which leads me to believe that it's the
StackExchange client library which is the culprit.

—
Reply to this email directly or view it on GitHub
https://github.com/StackExchange/StackExchange.Redis/issues/259.

[mgravell]

The thought occurs that if the server version is the problem, I should
attempt to recognise a few known endpoints and set a better default version
automatically.
On 13 Aug 2015 8:48 am, "kobybecker" [email protected] wrote:

I have this code snippet on LinqPad

Lazy lazyConnection = new Lazy(() =>
{
return ConnectionMultiplexer.Connect(".redis.cache.windows.net,abortConnect=false,ssl=true,password=");
});

var connection = lazyConnection.Value;
var server = connection.GetServer(connection.GetEndPoints()[0]);
Console.Write(server.Keys(connection.GetDatabase().Database, "prefix*"));

This just hangs in the Keys call, and never returns back. The cache is
quite responsive, and I'm able to make similar request from the redis-py
python client library, which leads me to believe that it's the
StackExchange client library which is the culprit.

—
Reply to this email directly or view it on GitHub
https://github.com/StackExchange/StackExchange.Redis/issues/259.

[deepaknc]

The server version is 2.8. I look at the IEnumerable returned, and it looks like it's using SCAN, because the values are not populated until I start iterating it. The administration commands are enabled. does it make sense?

[NickCraver]

@deepaknc which version of the library are you on, and can you try latest? The current code will automatically use the most efficient version to do a keys enumeration.

[mgw854]

I ran into this same problem and found this issue, so I thought I'd respond for those who might come looking:

In a database with 11 million keys, the server.Keys call just hangs for what seems like forever. When I log into the server using redis-cli and runs KEYS with the same filter value, I get back the results I expect in about 1.3 seconds. The problem isn't with StackExchange.Redis, so much as how I was using it. While paging over records using SCAN seems efficient (from the perspective that the Redis server doesn't block for very long), it's actually painfully slow using the default (10 keys per page). I upped that to 1,000 keys and saw my wait drop to 79 seconds. Moving to 10,000 keys per page saw my wait drop to 13 seconds, with each page returning in about 15 ms. Obviously, your results may vary and should be tested with representative data in your environment before making decisions.