Performance: Server-side pagination

[richard-cox]

• This issues covers the integration of server-side pagination with the dashboard
• This will come in a number of iterations, each will be listed here when agreed on
• [x] rancher/dashboard#9478
• [x] rancher/dashboard#9499
• [x] rancher/dashboard#9545
• [x] rancher/dashboard#9964
• [x] https://github.com/rancher/dashboard/issues/11507
• [x] https://github.com/rancher/dashboard/issues/11495
• [x] https://github.com/rancher/dashboard/issues/11496

2.9 cut off

• [x] https://github.com/rancher/dashboard/issues/11497
  • https://github.com/rancher/dashboard/pull/11505

2.10 cut off (WIP)

• [ ] https://github.com/rancher/dashboard/issues/11494
• [ ] https://github.com/rancher/dashboard/issues/11498
• [ ] https://github.com/rancher/dashboard/issues/11499
• [ ] Remove usages of $fetchType for secondary types that support pagination (aka individual workload lists)
• [ ] https://github.com/rancher/dashboard/issues/10283
  • [ ] #9494
  • https://github.com/rancher/dashboard/pull/11663
• [ ] rancher/dashboard#9546
  • [ ] https://github.com/rancher/dashboard/pull/11672
  • [ ] #11674
  • [ ] Chunk up catalog/load
• [ ] rancher/dashboard#9547
• [ ] rancher/dashboard#9965
• [ ] List of 2.10 regressions
• [ ] https://github.com/rancher/dashboard/issues/10417 (can be split up as per remove usages of findAlls)
• [ ] rancher/dashboard#9548
• [ ] rancher/dashboard#9966
• [ ] rancher/dashboard#9549
• [ ] #11513
• [ ] Compare / Record filtering requirements from shell/components/SortableTable/filtering.js, discuss with backend
• [ ] Investigate impact of displaying model's warped state but filtering/sorting via native metadata.state.name
• [ ] rancher/dashboard#9550
• [ ] Documentation for team. How to use pagination. When to use findAll.
• [ ] Back out changes that are now obsolete (ui performance related - list manual refresh, list incremental loading, list filter by project / namespace)
  • Note quite pagination related, but might impact above, we should also pick a web worker (simple / advanced) OR remove entirely (if we're not processing 100s of messages a second we might not need to process in a separate thread)

Backend Issues (not complete list)

• https://github.com/rancher/rancher/issues/45635
• https://github.com/rancher/rancher/issues/46348

Related

• https://github.com/rancher/dashboard/issues/11993
• https://github.com/rancher/dashboard/issues/11994
• https://github.com/rancher/dashboard/issues/11995

This issue requires a QA template.

[richard-cox]

Some of the backend changes have already been implemented in 2.7.2

• SURE-5387 - https://github.com/rancher/rancher/issues/38427
  • Some docs on the new UI are at https://github.com/rancher/steve#readme, https://github.com/rancher/rancher/tree/release/v2.7/tests/v2/integration/steveapi#readme

Anything marked as Development note are implementation details for this issue and are candidates to spin out

Some are incoming in 2.7 Q2

• SURE-5698 - https://github.com/rancher/rancher/issues/40141
  • Adds required searching
  • Development note - only single search term is supported. searching by multiple terms locally seems broken anyway https://github.com/rancher/dashboard/issues/8042
  • Filtering by one or more projects or namespaces
  • Development note - NOT is supported, aka filter by NOT list of system namespaces (i.e. user namespaces)
  • Development note - a maximum of 50 individual namespaces are expected. We need to handle this in UI

Some that we would like for 2.7 Q2 but are not blocking (in order of importance)

• SURE-5733 - https://github.com/rancher/rancher/issues/40771
  • Filtering/Sorting by aggregated fields (for instance Deployment Pod restarts)
  • Without this adoption is limited (feature can only be used in lists that don't have aggregated fields
• SURE-5734 - https://github.com/rancher/rancher/issues/40773
  • Socket updates for paginated lists
  • Development note - See comments in 5734 for details on how we will mitigate it (receive all in socket but only persist to store the entries within the page)
• SURE-5735 / SURE-5897 - https://github.com/rancher/rancher/issues/40772
  • Pagination of virtual resource (for instance Workloads)
  • Development note - If this is not delivered we would need to hide the Workloads list. We could have an overview page instead

In addition we need to consider more advanced ways to search

• Sort ip addresses in a more numerical way (need to also consider ip6)
  • e.g. xx.xx.17.196, xx.xx.17.2, xx.xx.17.204, xx.xx.17.24, xx.xx.17.243 and should be sorted numerically-octet-wise.
• Sort by duration
  • e.g. 7d4h, 6m56s, 23h should be 6m56s, 23h, 7d4h
• There's some more examples over at https://github.com/rancher/dashboard/issues/9782, but the remaining ones are generally around properties that have been computed client side and therefore can't be supported using server side pagination

[richard-cox]

The backend will not support sorting/filtering on 'calculated' fields e.g. current model getters. For the first iteration we should concentrate on badly performing lists that don't need them, this does include all workload types and secrets.

Possible Flow

• user changes pagination based setting
• list persists them in the cluster store
• list shows loading / in progress indicator?
  • tracked in component or store? what happens if long running http request, user leaves, user returns?
• list triggers a cluster/request (via resource-fetch)
• cluster/request uses store settings to make http request (ignores values in vuex store)
  • this includes namespace/project filters
• list receives page
• list cancels loading / in progress indicator

Question

• Do we reset these when a user returns to a previous list? What happens if the page has changed and now has no entries?
• How do incremental loading and manual refresh tie in?
• How do we work with / around lack of restriction to subscriptions (i.e. we still need to subscribe for all resource change events)
  • What happens if a resources changes that would alter page?

[clayrisser]

I wanted to say this 2 years ago, but I decided to wait and give Rancher time to improve. I can't help but notice this issue is a year old. Still, in 2024 Rancher's performance makes the product completely unusable, while alternative tools are fast and snappy.

I quit using Rancher because it's soooo slow. It's hogging 4 GB memory and 4 CPUs on a brand new cluster. It's been doing this ever since rancher 2.6 and there seems to be no improvements.

I don't understand how alternative tools can be so fast, while the rancher dashboard just freezes all the time because the rancher server CPU and Memory get maxed out. Makes no sense to me.

1 user, 1 cluster, 4 gb ram, 4 cpus and it's still not enough, and it's been this way for years. It's the one issue that's forced me to look for alternatives.

The rancher product feature set is great, but I really wish I could say the same about its performance.

[richard-cox]

@clayrisser This is a year old, and I can empathise with the frustration you've experienced. We are very actively working on a solution though (see linked issues and their prs for UI progress). Unfortunately API side hit a road block which has delayed things a bit. I'm happy to say though that we are targeting a tech preview of the feature in 2.9.0.

In addition 2.9.0 contains many UI performance improvements that assist both memory and CPU usage. It's worth giving that a try when released.

[clayrisser]

I will try again with 2.9.0, but if it requires running a large server, (more than 4 CPU) it's just not worth it.

I'm going to assume rancher works well for very large deployments that have resources to throw at it, but small deployments can't justify too many resources for it.