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
• Performance: Server-side pagination - Alpha #9478
• Investigate places where pagination is not supported #9499
• Performance: Server-side pagination - First, limited release #9545
• Restrict / Remove usages of findAll for config maps, secrets and pods #9964
• Server-side Pagination: Rancher Backups: Credential Secret does not show values #11507
• Server-side Pagination: Rancher UI becomes unresponsive when the user navigates to the Performance page and then to the cluster dashboard while server-side pag enabled #11495
• Performance: Rancher UI becomes unresponsive when user navigates to Performance page and then to Nodes page #11496
• Performance: Server-side pagination setting is enabled when user hits cancel option #11497
• Server-side Pagination: When a user clicks on the Refresh button on one page and navigates to another button does not appear #11494
• Server-side Pagination: Sorting: Cluster Dash: Newly created resource populates at bottom of list; sort order preference ignored #11498
• Server-side Pagination: Pods list not updated after resource deleted #11499
• Replace Workloads page / list with an overview page #11513
• Remove usages of $fetchType for secondary types that support pagination (aka individual workload lists)
• 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
• Application of selectors locally scales badly #10417 (can be split up as per remove usages of findAlls)
• Performance: Server-side pagination: home page cluster list #10283
  • Ensure home page cluster lists handles many many clusters #9494
• Performance: Server-side pagination - All Cluster Explorer primary level lists #9546
• Performance: Server-side pagination - Remaining cluster explorer lists #9547
• Restrict / Remove usages of findAll for all cluster explorer related resources #9965
• Performance: Server-side pagination - Cluster management lists & detail pages #9548
• Restrict / Remove usages of findAll for all cluster management related resources #9966
• Performance: Server-side pagination - Remaining lists & detail pages #9549
• Performance: Server-side pagination - Fully implemented #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)

• [EPIC] SQLite backed cache in the Steve API - iteration 1 rancher#45635
• [EPIC] SQLite backed cache in the Steve API - iteration 2 rancher#46348

This issue requires a QA template.

[richard-cox]

Some of the backend changes have already been implemented in 2.7.2

• SURE-5387 - [RFE] Steve should support pagination with sorting and filtering - Step 1 rancher#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 - [RFE] Add more advanced filtering options to steve rancher#40141
  • Adds required searching
    • Development note - only single search term is supported. searching by multiple terms locally seems broken anyway List search with multiple terms does not work as expected #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 - [RFE] Steve pagination: aggregated fields rancher#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 - SQLite backed cache: smarter WebSockets updates for paginated resources rancher#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 - [RFE] Virtual Resource Type to contain Multiple Resources rancher#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 Wrong sorting of various views and columns in Rancher UI #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.