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.
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.
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.
The server version is 2.8. I look at the IEnumerable
@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.
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.
Most helpful comment
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 runsKEYS
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 usingSCAN
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.