Large application page sends too many requests and freezes browser

sentientmonkey commented 1 year ago

Checklist:

[x] I've searched in the docs and FAQ for my answer: https://bit.ly/argocd-faq.
[x] I've included steps to reproduce the bug.
[x] I've pasted the output of argocd version.

Describe the bug

One of my applications in production is a fairly large monolith that has a number of varying deployments. This results in a high number of items to sync (264) and an even higher number of items to keep track of (around 1500 depending on autoscaling). The tree view has been unusable for us, but after upgrading from to 2.8.0 the list view has also started to freeze the browser due the sheer number of requests sent to the backend. I've been able to scale up our memory, cpu, & replica count to get through the requests, but users just have to wait until it subsides and they can finally start to use things like Deployment Status and Rollback, which is what they are trying to get to. Looking at the backend, I can see 2-3 requests made for each item - regardless of the current pagination set in the UI.

To Reproduce

Have a large number of items to track (pods/etc). Over 1000 items seems to be the difference for us in different environments.

Expected behavior

Server-side pagination would help this scale. But in the meantime, having a way to disable the app details view when there are too many items would help us making this more manageable for this app.

Screenshots

When loading this application's page here you can see the peak in traffic...

~6000 calls (each) {grpc_method="ListResourceLinks", grpc_service="application.ApplicationService"} {grpc_method="ListResourceActions", grpc_service="application.ApplicationService"}

~3000 calls (each)

{grpc_method="List", grpc_service="application.ApplicationService"} {grpc_method="CanI", grpc_service="account.AccountService"}

Version

argocd: v2.8.0+804d4b8
  BuildDate: 2023-08-07T14:25:33Z
  GitCommit: 804d4b8ca6bc4c2cf02c5c971aa923ec5b8623f0
  GitTreeState: clean
  GoVersion: go1.20.6
  Compiler: gc
  Platform: linux/amd64

Logs

Too many to include, but the grafana graphs above should give a fairly good insight

peturgq commented 10 months ago

I want to bump this as I can confirm I have this same issue with my monorepo deployment which has a couple of hundred components, tree view is completely unusable.

davidmontoyago commented 10 months ago

We're also experiencing this when loading a parent app with children Applications that contain large Daemonsets. In our case the degradation of the UI and the excessive API calls to ListResourceLinks, ListResourceActions and CanI only happens when using the view APPLICATION DETAILS LIST. It does NOT happen with the view APPLICATION DETAILS TREE or others. Can also confirm that on a Chrome browser, thousands of errors of the kind net::ERR_INSUFFICIENT_RESOURCES are reported in the web console.

ajrpayne commented 7 months ago

When I go to the APPLICATION DETAILS LIST view it calls can-i over and over again. Doesn't do this from the TREE view. v2.9.6

keyolk commented 7 months ago

I have a same issue : (

drmaciej commented 6 months ago

I can confirm the same is happening on v2.10.2, in list view, and the list is not that big - there are maybe 50 resources there.

ashutosh16 commented 6 months ago

I can confirm the same is happening on v2.10.2, in list view, and the list is not that big - there are maybe 50 resources there.

AFAIR This issue should have been fixed in v2..10. Can you provide screenshot of network tab and screenshot of UI where you see the issue. Is this issue happening when you use group node view?

McOffsky commented 5 months ago

I'm experiencing a lot of issues with browser freeze during Sync operation. My test app has 57 resource objects in it, and its smallest one from 115+ app that we host. Opening application page and starting sync generates over 11000 (!!!) can-i requests to backend. Most of them ends as net::ERR_INSUFFICIENT_RESOURCES error, even though we have pretty hefty infrastructure under it. All of those errors are fooding UI with errors about connectivity errors, which points to Networking/CrossOrigin error.

IMHO there is an issue in frontend app, but im no frontend dev. Yet the number of request suggests so :)

It's hard to make screenshots of the situation, as with browser whole computer freezes due to RAM limitations.

drmaciej commented 5 months ago

I can confirm the same is happening on v2.10.2, in list view, and the list is not that big - there are maybe 50 resources there.

AFAIR This issue should have been fixed in v2..10. Can you provide screenshot of network tab and screenshot of UI where you see the issue. Is this issue happening when you use group node view?

(Apologies for a late response)

I have not observed this issue in any other view, only in the list view, with the exact path being /applications/$ns/$app?view=list&resource=. Please find the screenshot attached. The gaps in the requests took place when I moved away from the page - when I refocused on it, the requests resumed.

All requests are made to:

/api/v1/settings
/api/v1/applications/$app/resource/actions?appNamespace=$appns&namespace=$ns&resourceName=$name&version=v1&kind=EndpointSlice&group=discovery.k8s.io
/api/v1/applications/$app/resource/links?name=$name&appNamespace=$appns&namespace=$ns&resourceName=$name&version=v1&kind=EndpointSlice&group=discovery.k8s.io

It's pretty much those 3 over and over again - the first one is always the same, the other two are for all resources present in my cluster. This couple was for a Service, then there were requests for other Services, then Pods, then Deployments, and so on. All in all - thousands of such requests and it seems to never end.

The can-i requests I used to see in previous Argo versions, but am not seeing them anymore (FYI @McOffsky).

argoproj / argo-cd

Large application page sends too many requests and freezes browser #15509