Possible performance degradation at edit configmap

[Cenness]

Setup

• Rancher version: 2.7.5
• Rancher UI Extensions: default
• Browser type & version: Firefox 115

Describe the bug

After updating dashboard from 2.6.1 to 2.7.5 I noticed very long page loading while trying to edit config on configmaps with lots of values. So big, that browser prompts to stop that tab. After pressing tab stop ui is immediately loaded, but values are not editable.

To Reproduce

1. get k8s cluster
2. install rancher dashboard
3. create cm with kv='';for n in $(seq 1 100);do kv="$kv --from-literal=key${n}=config${n}";done;kubectl create configmap big-cm $kv -n default
4. open it in rancher

Result

default view and edit yaml pages are loaded instantly
edit config ui hangs tab for 30+ seconds

Expected Result

edit config ui loads in less than 10 seconds and allows to edit and save values

Screenshots

N/A

Additional context

Not a frontender, but it sounds like you creating an instance of codemirror editor for each value field?
Adding replicas didn't help, here's metrics:

[richard-cox]

Would you be able to look at the browser's dev tools window's Network tab and provide a screenshot of the requests that have been made? There may be one in there that's stuck on pending or takes a long time to complete

[Cenness]

Here:

No new requests after loading finishes

Console errors most likely aren't relevant, as they are way before I got to cm. Here latest lines from it:

[richard-cox]

Would you be able to select the XHR tab on the right within the Network tab, hit refresh and post a screenshot of those network requests (might need a couple to show them all)?

Is this only an issue when navigating to the page (if so how many config maps are in the cluster) or also when refreshing?

[Cenness]

Issue not going away after refreshing. It loads slightly faster after I enabled rancher experimental garbage collection in global settings, but that may be just a wishful thinking.

665 configmaps
5700+ total resources

[richard-cox]

To be validated against server-side pagination feature. I'm assuming we're fetching all of a resource when we don't need to. Those cases will be removed as part of the pagination feature

[richard-cox]

Linking #9965