* There is a key sorting function, which has a penalty, because it sorts with natural compare, which means it is more human display, then just raw characters, but up to 100k the keys is still ok.
* There is a performance penalty for this application, given it uses AngularJS `ng-repeat` for the tree component. The best is if your application uses nested keys (something:nested:good), then the tree will be fast, but, for example, Nextcloud uses about 500 keys inline and it can take 5 seconds to generate the tree.
* Another solution is that instead of the : separator for your app, you can use the / separator. Then it will be much more responsive, see the settings tree separator - Nextcloud should use /
* A second solution is to use paging, the default paging is 50 keys
* Maximum keys for this App
* This application is usable up to 100k keys - given it pre-loads all keys and related info at once plus sorting - with natural comparing ...
* In that case, loading all keys into the browser takes about maximum 5-15 seconds
* For big key set to be usable paging should be a maximum 100 keys / page, though for 50 is the sweetest spot
* This application is not recommended with over 100k keys, because it might just crash the NodeJs server. I can understand there are use cases where you need over 100k keys, but this is not that p3x-redis-ui. To make it to work with large set vs more functional cute app, it would require a larger re-architecture, of course you can find a better software on the web for large sets or pure redis-cli.
* With some help, this could be implemented, but for now it looks like I will never use over 1k keys ...
* Besides, there are functions like sorting and tree options that are very nice vs large sets ...
This software is more functional than speed ...