Stackexchange.redis: Server.Keys()-Aufruf bleibt hängen

Welche Serverversion ist das und wie viele Schlüssel haben Sie? Auf der unteren Ebene
Server, auf denen nur KEYS verfügbar ist, ja: das kann schaden. Wenn SCAN ist
verfügbar ist, kann der Server dies verwenden, um Blockierungen zu reduzieren (mehrere kleine
Anfragen). Beachten Sie, dass bei deaktivierten Verwaltungsbefehlen die
Client kennt die Serverversion nicht - in diesem Fall sollten Sie dies explizit tun
teilen Sie der Bibliothek die Serverversion in den Konfigurationsparametern mit - it
wird standardmäßig auf einen sicheren untergeordneten Standardwert zurückgesetzt, wobei SCAN nicht als angenommen wird
erhältlich.
Am 13.08.2015 um 08:48 Uhr schrieb "kobybecker" [email protected] :

Ich habe dieses Code-Snippet auf LinqPad

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

var-Verbindung = lazyConnection.Value;
var server = connection.GetServer(connection.GetEndPoints()[0]);
Console.Write(server.Keys(connection.GetDatabase().Database, "Präfix*"));

Dies hängt einfach im Keys-Aufruf und kehrt nie zurück. Der Cache ist
ziemlich reaktionsschnell, und ich kann eine ähnliche Anfrage vom redis-py stellen
Python-Clientbibliothek, was mich glauben lässt, dass es die
StackExchange-Clientbibliothek, die der Übeltäter ist.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/StackExchange/StackExchange.Redis/issues/259.

Der Gedanke kommt auf, wenn die Serverversion das Problem ist, sollte ich
Versuchen Sie, einige bekannte Endpunkte zu erkennen und eine bessere Standardversion festzulegen
automatisch.
Am 13.08.2015 um 08:48 Uhr schrieb "kobybecker" [email protected] :

Ich habe dieses Code-Snippet auf LinqPad

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

var-Verbindung = lazyConnection.Value;
var server = connection.GetServer(connection.GetEndPoints()[0]);
Console.Write(server.Keys(connection.GetDatabase().Database, "Präfix*"));

Dies hängt einfach im Keys-Aufruf und kehrt nie zurück. Der Cache ist
ziemlich reaktionsschnell, und ich kann eine ähnliche Anfrage vom redis-py stellen
Python-Clientbibliothek, was mich glauben lässt, dass es die
StackExchange-Clientbibliothek, die der Übeltäter ist.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/StackExchange/StackExchange.Redis/issues/259.

Die Serverversion ist 2.8. Ich schaue auf die IEnumerablezurückgegeben, und es sieht so aus, als würde SCAN verwendet, da die Werte nicht aufgefüllt werden, bis ich mit der Iteration beginne. Die Administrationsbefehle sind aktiviert. macht das Sinn?

@deepaknc Welche Version der Bibliothek verwenden Sie und können Sie die neueste Version ausprobieren? Der aktuelle Code verwendet automatisch die effizienteste Version, um eine Schlüsselaufzählung durchzuführen.

Ich bin auf das gleiche Problem gestoßen und habe dieses Problem gefunden, also dachte ich, ich antworte für diejenigen, die vielleicht suchen:

In einer Datenbank mit 11 Millionen Schlüsseln bleibt der server.Keys Aufruf scheinbar ewig hängen. Wenn ich mich mit redis-cli am Server anmelde und KEYS mit dem gleichen Filterwert ausführe, erhalte ich die erwarteten Ergebnisse in etwa 1,3 Sekunden zurück. Das Problem liegt nicht an StackExchange.Redis, sondern daran, wie ich es benutzt habe. Während das Durchblättern von Datensätzen mit SCAN effizient erscheint (aus der Perspektive, dass der Redis-Server nicht sehr lange blockiert), ist es mit der Standardeinstellung (10 Schlüssel pro Seite) tatsächlich schmerzhaft langsam. Ich habe das auf 1.000 Tasten erhöht und meine Wartezeit auf 79 Sekunden gesenkt. Beim Wechsel auf 10.000 Tasten pro Seite sank meine Wartezeit auf 13 Sekunden, wobei jede Seite in etwa 15 ms zurückkehrte. Ihre Ergebnisse können natürlich variieren und sollten mit repräsentativen Daten in Ihrer Umgebung getestet werden, bevor Sie Entscheidungen treffen.