deployment resource details page hangs

[momkeller]

Setup

• Rancher version: 2.14.1
• Rancher UI Extensions: None
• Browser type & version: Chrome 147.0.7727.138; Edge 147.0.3912.98 ; Firefox 150.0.1

Describe the bug
extreme slowness in the UI (minutes for the page to be fully rendered and usable) and in many cases just hangs completely for the following views when a namespace has a lot (250+) of workloads:

• /dashboard/c/{cluster}/explorer/apps.deployment/{namespace}/{deployment}
• /dashboard/c/{cluster}/explorer/apps.statefulset/{namespace}/{statefulset}
• /dashboard/c/{cluster}/explorer/apps.daemonset/{namespace}/{daemonset}

It only appears to affect namespaces with many ( > 1-200) workloads, pods, services and ingresses.

Viewing pods in the same namesapce (dashboard/c/{cluster}/explorer/pod/{namespace}/{statefulset}) is fast.  same with configmaps, secrets, services, ingresses - all fast.

changing row count per page to 10 or 25 rows (vs 100) per page has no effect.

To Reproduce
have a cluster (ours is a K3s created and managed by rancher on a separate k3s cluster) with a namespace that has the follow resources:

• deployments = 300
• pods = 500
• ingresses = 230
• services = 280

1. select namesapce with many resources
2. go to the Deployments list page
3. click on a deployment entity that has an ingress

Result
deployment entity's details page is initially displayed and then freezes and takes ~150 seconds until it is fully loaded and browser tab is responsive again.

Expected Result
deployment entity's details page is displayed in full in less than a second.

Screenshots

Additional context

• when clicking on a deployment resource that does not have an ingress associated to it, the wait time is ~ 50s until the page is fully rendered
• when clicking on a deployment resource in a namespace with only 200 deployments and a a dozen or so ingresses, the page is fully rendered in under a second.
• screenshot shows Chrome debugger per tool call tree showing the slowness is inside the findMatchingIngresses function (index.vue lline 219).
• Chrome task manager shows that tab's cpu to be pegged at 99.3 while waiting for the page to render.
• the deployment list page is fast even with many( 1600+) deployment resources.
• issue affects daemonsets, deployments, statefulset details.

[richard-cox]

Possibly related, changes from component methods to class getters

- for (let k = 0; k < this.matchingServices.length; k++) {
-  const service = this.matchingServices[k];
+ for (let k = 0; k < this.value.relatedServices.length; k++) {
+   const service = this.value.relatedServices[k];

The change before that was from a year ago, and looks like it reduced the services/pods numbers to iterate over

[burgerjeffrey]

Is there a workaround for this?

[codyrancher]

@burgerjeffrey depending on the version you're on you should be able to append the legacy=true query param to the url.

[burgerjeffrey]

Thanks @codyrancher . Seems like a problem of scale really. If you wait long enough it does eventually load, but waiting could be minutes.

[codyrancher]

Yeah, I'll get a fix in soon and I plan to backport the fix.

Edit: It was caused by me and a naive solution so I'm sorry for those who have hit it.

[burgerjeffrey]

What does backport the fix mean, what version of 2.14 would it be available in?

[cernst-mx]

@burgerjeffrey depending on the version you're on you should be able to append the legacy=true query param to the url.

@codyrancher Thank you for the potential workaround. Where exactly would I add this? Or are you saying to just edit the URL each time a page hangs?