Bug #21508
closed
Browser struggles with very large number of input or output parameters
Description
User has a workflow that has 1000s of input parameters (or really one array parameter with 1000s of items).
This is making the browser nearly unusable.
We've addressed this in the collection file browser using FixedSizeList from the react-window package. I think we need to do something similar here.
We did some work on this previously (#20424) which moved the needle from completely unusable to barely usable. We decided at the time that it was good enough, but we now have users routinely running workflows with 1000s of parameters, so we need to revisit it.
Brett reports:
Similarly, trying to switch the Inputs pane from the list view to the JSON tab causes the page to become unresponsive for about a minute. Chrome prompts the user to force close the tab.
So we should make sure the JSON tab of inputs and outputs also renders in a reasonable amount of time.
Files
Updated by Peter Amstutz 11 months ago
- Related to Bug #21525: Process view unusable on running containers that are too verbose added
Updated by Peter Amstutz 11 months ago
- Related to Bug #20424: Process view page slowdown when inputs panel is ON and workflow with several thousands inputs added
Updated by Brett Smith 10 months ago
- Has duplicate Bug #21584: Poor Workbench performance when loading a workflow with an array input with >1K files added
Updated by Peter Amstutz 10 months ago
- Target version changed from Future to Development 2024-04-10 sprint
- Description updated (diff)
Updated by Peter Amstutz 10 months ago
- Target version changed from Development 2024-04-10 sprint to Development 2024-03-27 sprint
- Assigned To set to Stephen Smith
Updated by Brett Smith 10 months ago
Clicking basically any element on the page that significantly alters the DOM after inputs are loaded seems to take a long time. Things I have seen stall:
- Pressing the "Open log collection" button from the Logs pane
- Selecting a subprocess
- Closing the Inputs pane (after you do performance improves)
Updated by Peter Amstutz 10 months ago
From discussion: remove the image preview feature.
We brainstormed the idea of clicking on it to get a popup that shows the preview instead, that will be in a separate ticket.
Updated by Peter Amstutz 10 months ago
- Target version changed from Development 2024-03-27 sprint to Development 2024-04-10 sprint
Updated by Stephen Smith 10 months ago
- Related to Feature #21645: Add image preview to IO panel added
Updated by Stephen Smith 10 months ago
Changes at arvados|0682477f00b9aa7b3b4e27f331de7f3a07b2dabb branch 21508-io-panel-performance
Tests developer-run-tests-services-workbench2: #668
- All agreed upon points are implemented / addressed.
- Changed all rows to 46px for fixed height virtual list (for chips)
- Split out secondary and array parameters into separate parameters to accommodate virtual list indexing
- Removed image preview
- Implement virtual list with auto sizer
- Fixed Json tab sizing and scrollbars
- Add ellipses to any overflowing table cells
- Add cell values to tooltips in case values are cut off
- Removed image preview test and added scrollIntoView to cypress tests to handle virtual list rendering
- Fix unit test for io panel by mocking autosizer dimensions
- Anything not implemented (discovered or discussed during work) has a follow-up story.
- Re-add image preview #21645
- Code is tested and passing, both automated and manual, what manual testing was done is described
- automated tests updated
- manually tested with inputtest tordo-xvhdp-8jmlh4u27egffe3
- wgs tordo-xvhdp-l3mfpzf64ro5oyu
- Tested up to 400K rows
- Documentation has been updated.
- n/a
- Behaves appropriately at the intended scale (describe intended scale).
- behaves as expected up to 400K rows (then we run into the browser scroll height limit, issue with react-window with more than 447392 rows which = 17895700px https://github.com/bvaughn/react-window/issues/735)
- Considered backwards and forwards compatibility issues between client and server.
- n/a
- Follows our coding standards and GUI style guidelines.
- yes
Updated by Lucas Di Pentima 10 months ago
I've been doing some blind testing, first using the synthetic CR from #20424 (for example: tordo-xvhdp-v8zdvytsbzzlw0t) and I saw a load time of about 50% the 2.7.1 version. Significant improvement, but for some reason I was expecting bein blown away. (see Firefox profiler traces attached)
These tests were made on a limited resource Ubuntu VM: 1 core & 4 GB of RAM using Firefox.
So, I tested it on a production cluster that we're having issues with. There was no noticeable improvement there and that was surprising. After some more testing I realized that one (probably important) difference between the production container and the test container is that the inputs list was also included on the "command" panel.
So, after some debate we've come to the conclusion that this panel could be another source of slowdown and that we can benefit of implementing virtual list there.
Also, the inputs JSON tab is super slow.
Updated by Stephen Smith 10 months ago
- Status changed from In Progress to Resolved
Command panel will be handled in #21651
Updated by Stephen Smith 10 months ago
- Related to Feature #21651: Use virtual lists for panels with large amounts of text added