redis-commander
redis-commander copied to clipboard
Can we have an option to not load nav tree at start?
Since we have a large dataset, the UI crashed at start. The --root-pattern option is not an ideal one, cuz it'll still scan the database. btw we've set the --use-scan on.
Most of the time we don't need to navigate the tree since the number of keys is huge.
I think there's a lot of improvement to be made in the way that the keys get loaded in. If your database has millions of keys... it won't load. Ever. Times out on the front-end but still processes in the backend. At least that's what I'm experiencing.
Yes - noone really tested it with big dbs. To get an impression when its crashing/hanging - can you booth send the output of info keyspace and info memory for one such server please?
Another question - how do you use redis commander, what functions do you use? Not loading the tree at startup wont really help, because it crashes the first time you try to open the tree later on i think...
And as a workaournd: just add another redis connection to an (nearly) empty database as the first connection. The UI only tries to open the first one, all other connections in the tree view stay closed until opened explicit.
Another question - how do you use redis commander, what functions do you use? Not loading the tree at startup wont really help, because it crashes the first time you try to open the tree later on i think...
We just use the CLI part and there is no demand for navigating the tree.
And as a workaournd: just add another redis connection to an (nearly) empty database as the first connection. The UI only tries to open the first one, all other connections in the tree view stay closed until opened explicit.
We are now using the workaround you mentioned.
We use redis for caching, short-lived data objects for processing and ardb (redis protocol compatible) for persistence of event/log streams on disk.
I don't know if this is possible, but some environment/CLI flag for adjusting the read/write timeout on front-end requests would be the sort of stop-gap solution I'd like. We regularly use the tree (even though there's no search! ctrl+f) to get an understanding of the objects at a certain key's namespace (aka depth - we use ":" as the folding character)
Optimally, we would have some a websocket connection streaming the results in as they are processed from the backend so that even large databases will not time out the tree load. This type of capability would also help in implementing a function for scanning a particular stream for a value or k/v pair, as that could be a long-lived process that's more heavy on the backend of redis-commander than redis itself (for lack of a stream scanning function in redis protocol).
Thanks for feedback. will have a look at it but cannot promise anything as there is spare time only to work on these (and holiday season). Therefor any help is welcome.