Bug #21508
closed
Browser struggles with very large number of input or output parameters
Added by Peter Amstutz 3 months ago.
Updated about 1 month ago.
Release relationship:
Auto
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
- Description updated (diff)
- Related to Bug #21525: Process view unusable on running containers that are too verbose added
- Related to Bug #20424: Process view page slowdown when inputs panel is ON and workflow with several thousands inputs added
- Description updated (diff)
- Has duplicate Bug #21584: Poor Workbench performance when loading a workflow with an array input with >1K files added
- Target version changed from Future to Development 2024-04-10 sprint
- Description updated (diff)
- Target version changed from Development 2024-04-10 sprint to Development 2024-03-27 sprint
- Assigned To set to Stephen Smith
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)
- Status changed from New to In Progress
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.
- Target version changed from Development 2024-03-27 sprint to Development 2024-04-10 sprint
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.
- Code is tested and passing, both automated and manual, what manual testing was done is described
- Documentation has been updated.
- Behaves appropriately at the intended scale (describe intended scale).
- Considered backwards and forwards compatibility issues between client and server.
- Follows our coding standards and GUI style guidelines.
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.
- Status changed from In Progress to Resolved
- Related to Feature #21651: Use virtual lists for panels with large amounts of text added
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by