Ich arbeite an einigen .NET-Web-Apps, die Redis stark zum Caching zusammen mit dem Redis-Client von ServiceStack verwenden. In allen Fällen habe ich Redis auf demselben Rechner laufen. Ich habe BasicRedisClientManager und PooledRedisClientManager (immer als Singletons implementiert) und hatte einige Probleme mit beiden Ansätze.Wie verwalten Sie Redis-Verbindungen am besten mit ServiceStack?
Mit BasicRedisClientManager würde die Dinge für eine Weile gut funktionieren, aber schließlich würde Redis Verbindungen ablehnen. Mit netstat haben wir entdeckt, dass Tausende von TCP-Verbindungen zum Standard-Redis-Port im TIME_WAIT-Status herumhingen.
Wir wechselten dann zu PooledRedisClientManager, die das Problem sofort zu beheben schien. Aber nicht lange danach bemerkten wir vereinzelte CPU-Spitzen, die wir auf Threadwarte (System.Threading.Monitor.Wait-Aufrufe) beschränkten, verursacht durch PooledRedisClientManager.GetClient.
Im Code verwenden wir einen Get-In-Get-Out-Ansatz (mit den praktischen Execas-Shortcuts von ServiceStack). Daher werden Verbindungen in der Regel sehr häufig erfasst, aber so kurz wie möglich gehalten.
Wir bekommen eine geringe Menge an Traffic, aber wir sind kein StackExchange, und ich kann mir nicht helfen, aber denke, dass der ServiceStack-Client dem Job gewachsen ist und wir nur etwas falsch machen. Ist PooledRedisClientManager der richtige Ansatz hier? Wäre es ratsam, einfach die Poolgröße zu erhöhen? Oder maskiert das wahrscheinlich nur ein Problem mit unserem Code?
Nur auf der Suche nach allgemeinen Leitlinien hier, ich habe keinen spezifischen Code, ich brauche Hilfe an dieser Stelle. Danke im Voraus.
Reine und totale Spekulation - Ich habe AppHarbor benutzt und hatte Probleme mit Redis-Verbindungen, die gehalten wurden und Redis-Verbindungslimits erreichten. Die Websites erhalten praktisch keinen Datenverkehr, daher spekuliere ich, dass IIS die Idle-Timeout-Zeit überschritten hat und meine App heruntergefahren wurde und Redis-Verbindungen irgendwie nicht richtig verteilt wurden. Die 'RedisClientManagers' von SS behandeln jedoch das Schließen von Verbindungen auf 'Dispose'. Wiederum nur Spekulationen, aber ein paar IIS Leerlauf-Timeouts ohne Verbindungen und einige 'Application_Starts', die neue Redis-Verbindungen erzeugen, scheinen ein plausibler Täter zu sein. – paaschpa
Sind Sie sicher, dass Ihre Verbindungen geschlossen sind? Überprüfen Sie den Befehl CLIENT LIST mit redis-cli –