Closed gaktive closed 3 years ago
My checks PASSED
Reproduction Environment:
Rancher version: v2.6.0 Rancher cluster type: single-node docker install Docker version: 20.10
Downstream cluster type: RKE2 Downstream K8s version: v1.21.4+rke2r2
Reproduction steps:
Create an RKE2 cluster (cluster type does not matter). We will use this for most of our testing. With our fresh v2.6.0 box, explore the new RKE2 cluster, on the left pane, go to More Resources > RBAC > ClusterRoleBindings. Filter the table, it's pretty responsive and fast with this count of ClusterRoleBindings (under ~100 out of the box). Perhaps up to a 100ms delay from me typing to the results showing if I had to guess. This works fine.
Now, I'll execute a python script that will essentially create many ClusterRoleBindings (the issue mentioned RoleBindings but it doesn't matter this still tests filtering of large tables the same).
I already observe a decrease in performance with as little as 300 objects in 2.6.0.
I observe significant slowness with about 700 objects. Now filtering takes about a second or so instead of being snappy 100ms approx.
Last, at about 1200 objects I see further performance degredation when filtering thru the table of ClusterRoleBindings. I have successfully reproduced. Maybe a couple of seconds tops to return most results.
Validation Environment:
Rancher version: v2.6-head 4df101e
9/28/21
Rancher cluster type: single-node docker install
Docker version: 20.10
Downstream cluster type: RKE2 Downstream K8s version: v1.21.5+rke2r1
Validation steps:
Additional Info: I'd like to be able to more accurately compare the timings change but wasn't able to find a good way to do this, so this was based on observation. However, I'm confident the change was a success and an improvement.
There's a performance problem when using Cluster Explorer (Dashboard) whereby when the number of queryable items gets large (e.g, 5000 rolebindings), the responsiveness of the UI slows down. When starting to type in a query, the automatic filtering kicks in with each key press.
This is most prominent in group projects, whereby the namespace view responds quicker.
Based on @vincent99's initial look, we need to look at the actual search logic and caching since it appears we're going through the entire list of objects despite each key press should be relying on a shorter list of objects.
We should also look on Openshift since we're maybe searching more than other tools do (e.g, the actual keys of each secret & configmap) as we aren't just loading the Kubernetes table views like kubectl does.