Bug 1934229

Summary: List page text filter has input lag
Product: OpenShift Container Platform Reporter: Jon Jackson <jonjacks>
Component: Management ConsoleAssignee: Jon Jackson <jonjacks>
Status: CLOSED ERRATA QA Contact: Siva Reddy <schituku>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.8CC: aos-bugs, jokerman, spadgett, yapei
Target Milestone: ---   
Target Release: 4.8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: Scrubbed
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: Filter logic was being applied on every key stroke when using list page name filter Consequence: When there are a large number of items on the list page, the filter logic would cause lag on the name filter input Fix: Debounce the filter function with a 200ms delay Result: Name filter input works smoothly and filter is only applied after a 200ms delay without new input.
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-07-27 22:49:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jon Jackson 2021-03-02 18:19:42 UTC
Description of problem:
Performance of the text filter on the list pages can get very sluggish with larger numbers (n) of items. Even with n as low as 20, there is noticeable input lag. 

Version-Release number of selected component (if applicable):
4.8

How reproducible:
Always

Steps to Reproduce:
1. Visit Workloads > Secrets page
2. Select "All Namespaces" from the Project dropdown (should be hundreds if not thousands of Secrets on most clusters)
3. Start typing a term in the "Search by name..." filter

Actual results:
There is noticeable input lag. With n in the dozens, it's probably only about 200 milliseconds of lag, but still noticeable. Lag increases with n and can even take longer than a second (estimated) in some cases.

Expected results:
Text input should be immediately responsive, regardless of the list length.

Additional info:
This is happening on a MacBook Pro with average performance (maybe even above average) and plenty of available CPU/memory. I would imagine the issue would get better or worse depending on the performance and available compute resources of the user's machine.

Comment 1 Jon Jackson 2021-04-07 13:24:52 UTC
Started looking into this. The performance issue doesn't seem to be tied to the filtering logic itself. Even after removing the filtering logic altogether, there were still performance issues. I suspect that updating the URL search params is causing extra re-renders. Will investigate more next sprint.

Comment 4 Siva Reddy 2021-06-11 17:10:05 UTC
Version:
 4.8.0-0.nightly-2021-06-11-024306

Steps to verify:
  Did a comparison between 4.7 and 4.8 and you do see the input gets stuck in 4.7 but it runs smooth in 4.8

1. login to console and navigate to Workloads>Secrets
2. Uncheck all in the filter drop down and select "Name" in the next drop down and type "sdn-controller" in the "Search by name" input box.
3. It will display 4 filtered values that have "sdn" "controller" words (actually it is filtering by characters)
4. press and hold backspace in the name filter and watch the url getting updated and the characters in the "Search by name" 
    input box

in 4.7 you see a significant time lag between the updates in the url and input box characters where input box chars are updated after a delay
but in 4,8 both of them getting updates almost simultaneously.

  there is definitely improvement and hence it is verified

Comment 7 errata-xmlrpc 2021-07-27 22:49:01 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.8.2 bug fix and security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:2438